From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5921 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: compiling musl on x86_64 linux with pcc Date: Wed, 27 Aug 2014 03:54:07 -0400 Message-ID: <20140827075407.GL12888@brightrain.aerifal.cx> References: <20140813091843.GD5170@example.net> <20140813123832.GK12888@brightrain.aerifal.cx> <20140813125607.GK5170@example.net> <20140813142332.GN12888@brightrain.aerifal.cx> <20140825082807.GB12376@example.net> <20140825083457.GC12376@example.net> <20140825154617.GV12888@brightrain.aerifal.cx> <20140826193439.GH12376@example.net> <20140826195407.GG12888@brightrain.aerifal.cx> <20140827074036.GI12376@example.net> 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 1409126072 15498 80.91.229.3 (27 Aug 2014 07:54:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Aug 2014 07:54:32 +0000 (UTC) Cc: musl@lists.openwall.com To: u-igbb@aetey.se Original-X-From: musl-return-5928-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 27 09:54:25 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XMY3h-0000Up-SN for gllmg-musl@plane.gmane.org; Wed, 27 Aug 2014 09:54:21 +0200 Original-Received: (qmail 11287 invoked by uid 550); 27 Aug 2014 07:54:21 -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 11276 invoked from network); 27 Aug 2014 07:54:21 -0000 Content-Disposition: inline In-Reply-To: <20140827074036.GI12376@example.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5921 Archived-At: On Wed, Aug 27, 2014 at 09:40:36AM +0200, u-igbb@aetey.se wrote: > > in fact, as I explained before, there is only one correct > > implementation: builtin functions like __builtin_va_arg, etc. but > > possibly with gratuitously different names or argument orders. In any > > case there is no way to simply "let the compiler do it" because > > certain other headers need to access or expose the va_list type, and > > doing this with a compiler-provided stdarg.h requires knowledge of the > > compiler versions internals in the libc headers, which is much worse > > than the current situation. > > The current situation is (!) actually using knowledge of the compiler > in the library headers (checking for gcc version, as you noted when we > were talking about tcc), which shouldn't be needed if the library would > skip referring to the intimate knowledge of those details. This is only a hack that's left in the i386 headers for supporting ancient gcc versions that probably have not worked right for more than a decade. It should probably be removed, and bits/stdarg.h removed. > I am possibly not realizing some crucial bit but I do not see why the > implementation of stdarg.h must be the business of the library. If the Because other headers need to know how to get va_list defined for use in function prototypes, and they can't include stdarg.h because it would expose more than they want. glibc handles this by making use of a special inclusion protocol between the glibc headers and the gcc headers: it defines a special macro before including stdarg.h telling gcc that it just wants the definition of va_list and nothing else. > compiler *building* the library wants the va_arg to be __builtin_va_arg, > then you get the same functionality / efficiency as now, otherwise you > get a less efficient but still fully compatible library, don't you? No. This has absolutely nothing to do with efficiency. > A compiler used *together* with the library may lack the builtins but it > still can be fully compatible even if in some situations less efficient. No, it can't. There is simply no way to express, in C, the concept of "get the next variadic argument" without __builtin_va_arg or something 100% equivalent to it. If you have a compiler than chooses to be gratuitously incompatible and use a different name for its builtin, you can always add -D'__builtin_va_arg(x)=__foo(x)' etc. to your CFLAGS when using that compiler. However no such compiler seems to exist. > No compiler (if ABI-compatible) is allowed to produce code unusable when > linked to code compiled by another compiler. How allowing the compiler > to pick its own stdarg.h would lead to a less efficient code than otherwise? Again, this has nothing to do with ABI between external variadic functions. It's a matter of the inability to express to the compiler what you want it to do (get the next variadic argument) in plain C. Rich