[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151013150525.GP8645@brightrain.aerifal.cx>
Date: Tue, 13 Oct 2015 11:05:25 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com,
Aboriginal Linux <aboriginal@...ts.landley.net>
Subject: Re: Re: musl and kernel headers [was Re: system-images 1.4.2:
od is broken; bzip2 is missing]
On Tue, Oct 13, 2015 at 04:53:35PM +0200, Szabolcs Nagy wrote:
> * Denys Vlasenko <vda.linux@...glemail.com> [2015-10-13 14:10:24 +0200]:
> > On Fri, Oct 9, 2015 at 9:46 PM, Rich Felker <dalias@...ifal.cx> wrote:
> > >> Looking at kernel's libc-compat.h, it looks like you can get away
> > >> with using __UAPI_DEF_foo's like this?
> > >>
> > >>
> > >> #if defined(__UAPI_DEF_SOCKADDR_IN) && __UAPI_DEF_SOCKADDR_IN == 1
> > >> /* kernel already defined the struct, do nothing */
> > >> #else
> > >> struct sockaddr_in {
> > >> ...
> > >> };
> > >
> > > This would address the case where the kernel header is included first,
> > > but it's not a case I or most of the musl community wants to support,
> > > because there's no guarantee that the kernel's definitions of these
> > > structures will actually be compatible with use elsewhere in the libc
> > > headers, etc.
> >
> > If kernel's definition does not match yours, there is a much
> > bigger problem than "includes do not compile":
> > kernel and userspace definitions of these structs *must* match
> > (modulo harmless things like different typedef names for field types).
> >
> > So in this case either kernel or libc would need to be fixed.
>
> why?
>
> in practice most types are c abi compatible with the kernel
> because translating the types at the syscall boundary is
> painful/impossible.
>
> but even with compatible binary representation there is
> plenty space for disagreement between kernel and libc on
> the source level. (of course code that includes both libc
> and kernel headers might not care about posix namespace
> violations or undefined behaviour in kernel headers..)
>
> and libc-compat does not cover all conflicting cases
> (i assume they just add workarouds when somebody hits
> a conflict), e.g. sys/inotify.h and linux/inotify.h are
> in conflict (and linux/inotify.h is not even standard c).
Indeed the problem here is source compatibility, not binary
compatibility. Issues like names of types, choice of distinct types
that have the same size and representation but which are not
compatible types (which make problems if you take the address of the
member, including possibly aliasing problems which are real-world
bugs), etc. If static linking of libc is used along with LTO these
could spill deep into internals and result in broken codegen.
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.
