[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 28 Aug 2015 00:21:04 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Adjustments to roadmap
On Thu, Aug 27, 2015 at 08:38:16PM -0700, Khem Raj wrote:
> On Thu, Aug 27, 2015 at 7:43 PM, Rich Felker <dalias@...c.org> wrote:
> > Hey everyone,
> >
> > Between travel for a CII meeting last month (from which there's
> > exciting stuff I still need to follow up on, especially tlsify), work,
> > and making personal time to enjoy the summer, I've gotten rather
> > behind on musl releases. I think I'm caught up with everything
> > important for 1.1.11 though, and plan to release it ASAP.
> >
> > During this period of release delay, I haven't been updating the
> > roadmap on the wiki, but lots of new ideas have come up for enhancing
> > musl that may be appropriate to prioritize somewhere in the next few
> > release cycles. I'd like to share some of them here and get feedback
> > on what the community/users would like to see:
> >
> > ----------------------------------------------------------------------
> >
> > 1. Unifying static/shared libc .o files.
> >
> > Right now, all the files in musl are built twice, once as .o for
> > inclusion in libc.a, and once as ".lo" (my naming convention) for
>
> ..lo is conflicting with libtool generated objects btw.
Yes. Since we're not using libtool that doesn't matter but it may be
confusing to some people who see it.
> > inclusion in libc.so. This of course requires twice the time and space
> > to build, and also has semi-gratuitously separate code paths that need
> > to be maintained. I would like to eliminate that.
> >
> > One of the obvious big reasons for building libc.so's files separately
> > is that they need to be PIC. But for static-PIE support, which musl
> > now has and which I'm trying to get upstream in GCC/binutils, libc.a
> > needs to be built as PIC too. I did some tests, and the size increase
> > of libc.a by using PIC is about 1-3% on "important" archs and still
> > only 4-6% on some of the worst ones. I don't have figures on
> > performance cost, though, and it's harder to measure.
> >
> > If we do get rid of the dual-build, it will still be possible to build
> > a non-PIC libc.a via something like --disable-pic, which would imply
> > --disable-shared. It would just be a separate run of the build, which
> > is somewhat inconvenient now but much less so if we add out-of-tree
> > build support. And of course getting rid of the double-build in the
> > makefile would simplify it and make developing out-of-tree build
> > support easier.
>
> This seems a good proposal. We need some data on arches like mips
MIPS is always semi-PIC anyway, so the size increase is fairly minimal
there -- about 3%. Actually I'm a bit puzzled why it's even that much.
> > 3. Symbol versioning
> >
> > Right now musl's dynamic linker ignores symbol versioning information
> > except to select the "current" version of a symbol the same way ld
> > does. This is sufficient for most things, if you don't want to support
> > old library ABIs and mixed (i.e. broken) ABIs, but it breaks some
> > hacks GCC is doing in their target libs (libgcc_s.so, ...), and some
> > setups that arguably "should" work, especially for C++ apps. What's
> > probably worse is that you get silent breakage when an app is trying
> > to use symbol versioning, expecting it to work, and it doesn't.
> >
> > I don't think the status quo is a reasonable option. We should either
> > teach GCC that musl targets don't support symbol versioning, and make
> > sure apps/libs' build systems detect this, or we should make them
> > work. My leaning is towards the latter.
>
> we can detect using triplets so apps should be able to conflgure for musl.
> I think symbol versioning could be a good thing for musl for backward
> compatibilty with itself
> who knows what future holds for musl, we might have to deal with own
> past. but it should be a build time
> option, for glibc if we disable versioned symbols code size reduces
> significantly.
Symbol versioning is generally not a valid approach to libc ABI
problems, because it only addresses the ABI between a consumer of the
library and that library, not the ABIs between multiple consumers of
the library (e.g. an app and another library that both use types from
libc). It's also broken in that the version is bound at link-time, but
what matters is the version code was using at compile-time. This
distinction screws up the behavior for static linking completely.
So I think we can confidently say versioning of libc symbols does not
have any place in musl. (Also, if libc.so had a version table, it
would break glibc ABI-compat completely since the version strings
would not match the caller's references. If we support version tables,
libc.so actually needs to ensure at runtime that any symbol table it
has gets ignored, since it might inadvertently pick up versions from
the compiler runtime libgcc.a/etc. in the future.)
> > In addition to the above, there are all of the existing roadmap items
> > on the wiki which are open for discussion of how they should be
> > prioritized. The big projects are roughly:
> >
> > - Atomics refactorization/deduplication
> > - Bits refactorization/deduplication
> > - Out-of-tree builds
> > - LC_COLLATE
> > - IDN
> > - Advanced glibc ABI-compat features in dynamic linker
> > - Documentation
>
> how about nommu ?
I think the 1.1.11 release will cover most of the generic NOMMU
support considerations, but we could add:
5. FDPIC entry point and dynamic linker code.
6. Support for building as pure thumb2 code for ARM Cortex-M.
Did you have other NOMMU needs in mind?
> > Apologies for the slow progress lately. Don't worry though, there's
> > still lots more good stuff to come for musl.
>
> Some goals around code size might be interesting too.
Anything particular in mind?
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
