[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130725195955.25cbc101@vostro>
Date: Thu, 25 Jul 2013 19:59:55 +0300
From: Timo Teras <timo.teras@....fi>
To: musl@...ts.openwall.com
Cc: dalias@...ifal.cx
Subject: Re: Preparing to release 0.9.12
On Thu, 25 Jul 2013 12:16:55 -0400
Rich Felker <dalias@...ifal.cx> wrote:
> On Thu, Jul 25, 2013 at 10:44:59AM +0300, Timo Teras wrote:
> > On Wed, 24 Jul 2013 16:02:21 -0400
> > Rich Felker <dalias@...ifal.cx> wrote:
> >
> > > The list of changes since 0.9.11 has grown quite large, and
> > > although we haven't met some of the roadmap goals for 0.9.12,
> > > others that were marked for 0.9.13 have already been finished. So
> > > I think it's reasonable to aim to release very soon now. There
> > > are still a few pending items I'd like to get committed before
> > > the release:
> > >
> > > - orc's getaddrinfo fix for AF_UNSPEC with NULL hostname
> > > - Andre's ARM memcpy optimizations
> > > - New crt1.c code for adding PIE support for more archs
> > > - MAYBE the symlink direction issue...
> >
> > Since the C++ ABI was fixed, it means that any current native musl
> > toolchain will get C++ ABI breakage?
> >
> > In this case the symlink direction issue would help with smoother
> > transitions. It would be also crucial to start using proper SONAME
> > versioning, so we could handle binary upgrades smoothly.
>
> This would not help. The ABI between the application and musl's
> libc.so has not changed since just after the initial public release,
> except for some bugs that had arch-specific structures laid out wrong,
> etc. -- and in this case, programs built before the fix were not
> working at all anyway when using the affected feature.
The so versioning will not help for C++ related things. The most
important use case I had in mind is that, package managers that use
soversions for automatic dependencies, can insert proper "require
version XXX or later of this .so". That is, if we built with musl X, we
can detect that from .so, and record it. And later ensure that musl X-1
will not satisfy the newly built package's dependencies. Especially
important when we are introducing new symbols.
> What's affected by the C++ ABI compatibility changes is the ABI
> between C++ applications and third-party libraries built against
> musl's headers. As far as I know, there is no decent way around this
> with versioning (library versioning or symbol versioning). There are
> two ways this type of ABI linkage can come into play:
>
> - When the size of a type is not relevant to the interface between
> libc and its caller, but affects the size of structs containing the
> type, which another library might define and use as part of its
> interface with its caller.
>
> - When the C++ compiler encodes the exact underlying type (for
> non-aggregates) or the struct/union/enum tag into the mangled
> symbol name for functions which take the type as an argument, and
> both the caller and callee have to agree or you'll get unsatisfied
> symbol references.
>
> Because C++ ABI is so fragile, musl has not had an official C++ ABI
> until now. In fact, it's changed in subtle ways several times already
> this year due to other bugs found, where musl's idea of a type's
> identity disagreed with the compiler's idea of what it should be for
> the particular psABI. (These needed to be fixed because they affect
> things like printf format string warnings, and, for wchar_t, size_t,
> ptrdiff_t, and perhaps a few others, they really need to match the
> type of certain expressions (L"x", sizeof(x), p1-p2)). While
> compatibility with C++ libraries built against glibc is part of the
> motivation of the ABI-compat changes recently made, and equally
> important aspect is just _stabilizing_ the ABI. By having a target ABI
> to match (and test that we match), it's easy to know we don't have
> lingering type mismatch bugs and thus that we won't need to break the
> C++ ABI in the future.
>
> I apologize that the lack of C++ ABI stability was not warned about
> prominently in previous releases. If you (or anyone else) have
> deployed packages that you think will break, I can look into adding a
> layer in the dynamic linker that would, when a C++ symbol lookup
> fails, try substituting differently-mangled symbols which differ from
> the desired one only in the nominal identity of the type but not in
> its size or representation. This would not be too hard, but unless
> it's needed, it's probably a bad idea.
Full agree. And no, no need for the symbol name "re"-mangling hack.
Still working on my initial build.
> Finally, please note that any breakage from the C++ ABI changes will
> be unresolved symbol errors at startup, not application misbehavior.
Yes. I figured this. And it would be namely on the C++ libraries. Not
on musl itself, as the musl symbols never changed. It's just C++
compiler's perception of the type names.
> > Relatedly, commit f389c4984a (make the dynamic linker find its path
> > file relative to its own location) introduced the armeb, armhf
> > variants. Fundamentally, these are distribution specific names. I
> > believe debian has/had armeb (big-endian OABI; being retired), arm
> > (little-endian OABI; dead port), armel (little-endian EABI), and now
> > armhf (little-endian EABI with hard-float). But these are by no
> > means standard. While it is good that LDSO_ARCH gets good default
> > with this distinguished. It should be allowed to be overridden by
> > distributions.
> >
> > So basically I'd like to give at configure time:
> > DISTRO_ARCH=armel
>
> Why? The goal isn't to match the distro's naming. It's to have a
> unified name for any musl-linked binaries using this arch, so that if
> you move them from one system to another (possibly with different
> distro) they still work. The arch and subarch names used are unique
> within the "ld-musl-..." namespace, so there's no danger of them
> conflicting with other things in the distro. If you would prefer
> different names, I would be happy to consider changing them at this
> point (since there hasn't been a release with them anyway). However, I
> think it's really counter-productive to use distro-specific PT_INTERP.
> All that does is prevent someone from using your musl binaries on
> another distro, or vice versa; the ability to do that is intended to
> be one of musl's advantages over glibc.
Well, now that you've added most needed subarches, I'm probably ok. I
was just anticipating that if toolchain gets new feature affecting ABI,
you need to track those all. But if you aim universal compatibility
then this needs to be done. I guess there will not be insane amount of
subarches, but you never know about future.
- Timo
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.
