From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8664 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: musl and kernel headers [was Re: system-images 1.4.2: od is broken; bzip2 is missing] Date: Tue, 13 Oct 2015 14:56:22 -0400 Message-ID: <20151013185622.GS8645@brightrain.aerifal.cx> References: <5612925A.4070402@landley.net> <20151006014426.GL8645@brightrain.aerifal.cx> <20151008165808.GZ8645@brightrain.aerifal.cx> <20151009194641.GI8645@brightrain.aerifal.cx> <20151013145335.GQ10551@port70.net> <20151013150525.GP8645@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1444762604 23020 80.91.229.3 (13 Oct 2015 18:56:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 13 Oct 2015 18:56:44 +0000 (UTC) Cc: musl , Aboriginal Linux To: Denys Vlasenko Original-X-From: musl-return-8676-gllmg-musl=m.gmane.org@lists.openwall.com Tue Oct 13 20:56:44 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Zm4kY-0007nS-8g for gllmg-musl@m.gmane.org; Tue, 13 Oct 2015 20:56:38 +0200 Original-Received: (qmail 10090 invoked by uid 550); 13 Oct 2015 18:56:36 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 10070 invoked from network); 13 Oct 2015 18:56:35 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8664 Archived-At: On Tue, Oct 13, 2015 at 08:02:47PM +0200, Denys Vlasenko wrote: > On Tue, Oct 13, 2015 at 5:05 PM, Rich Felker wrote: > >> > > 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. > > It's not that bad in practice. > > In C, typedefs are not new types. uint16_t, u16 and __u16 > are all just aliases to "unsigned short". > > You won't get a conflict because different typedefs > were used to declare a struct member whose address you are > taking and passing to some function. > If signedness and width match, then it will work without casts > or compiler errors. The problem is that u32 might be unsigned int or unsigned long (either possible on ILP32), u64 might be unsigned long or unsigned long long (either possible on LP64), etc. Also structs with different tags are distinct types. These are not ABI issues for machine-code object files but they are source-level compatibility issues and linking (arguably ABI) issues for LTO object files. They're also C++ issues; for instance it's possible that one translation unit declares a function taking a pointer to some network function without including the kernel header, and another defines it while including the kernel header, and the struct names or types mismatch (even in a layout-compatible way), the name mangling will be different and the code won't link. Rich