From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5864 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: va_list (was: [musl] compiling musl on x86_64 linux with pcc) Date: Fri, 15 Aug 2014 11:56:56 -0400 Message-ID: <20140815155656.GQ12888@brightrain.aerifal.cx> References: <20140813123832.GK12888@brightrain.aerifal.cx> <20140813125607.GK5170@example.net> <20140813142332.GN12888@brightrain.aerifal.cx> <20140814071055.GN5170@example.net> <20140814142056.GX12888@brightrain.aerifal.cx> <20140814143838.GR5170@example.net> <20140814144702.GZ12888@brightrain.aerifal.cx> <20140815104936.GA5170@example.net> <20140815134434.GP12888@brightrain.aerifal.cx> <20140815150722.GC5170@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 1408118237 2018 80.91.229.3 (15 Aug 2014 15:57:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Aug 2014 15:57:17 +0000 (UTC) Cc: musl@lists.openwall.com To: u-igbb@aetey.se Original-X-From: musl-return-5870-gllmg-musl=m.gmane.org@lists.openwall.com Fri Aug 15 17:57:11 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 1XIJsN-0004jv-2L for gllmg-musl@plane.gmane.org; Fri, 15 Aug 2014 17:57:11 +0200 Original-Received: (qmail 24276 invoked by uid 550); 15 Aug 2014 15:57:10 -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 24268 invoked from network); 15 Aug 2014 15:57:10 -0000 Content-Disposition: inline In-Reply-To: <20140815150722.GC5170@example.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5864 Archived-At: On Fri, Aug 15, 2014 at 05:07:23PM +0200, u-igbb@aetey.se wrote: > Hello Rich, > > On Fri, Aug 15, 2014 at 09:44:34AM -0400, Rich Felker wrote: > > > http://www.x86-64.org/documentation/abi.pdf > > > > > > I may be missing something but it looks like this ABI can not be an opaque > > > fully "compiler's internal business". Compilers may implement as much > > > optimizations as they wish but they must be able to produce interoperable > > > object files, don't they? > > > > Yes, but this all pertains to calls between (external or potentially > > externally visible via function pointer) functions. It has nothing to > > do with what happens inside the function once its called. > > > I'll try to explain with the (wrong) legacy stdarg.h macro definitions > > for i386 (much simpler) as an example. In > > Thanks for the detailed explanation. > > > void foo(int a, ...) > > { > > va_list ap; > > va_start(ap, a); > > int b = va_arg(ap, int); > > ... > > } > > > > the legacy macros are taking the address of a, adding 4 to it, and > > using the result to access the first variadic argument which is then > > stored in b. However, there is utterly no relationship between the > > address of a and the location where the variadic argument is stored! > > > There is a relationship between the addresses where the _value_ which > > is stored in the _local, automatic variable_ a is passed on the stack, > > I see. This is certainly the internal business of the compiler. > Nevertheless, as soon as a compiler offers an implementation > of finding the location of variadic variables, then it is bound > by its promises and has to generate code which corresponds to > this implementation. > > More advanced compilers implement this as builtins, less advanced > still may choose to implement this "in C" in stdarg.h without breaking > compatibility with other compilers (as long as the actual passing of > arguments conforms to the ABI). > > So I guess nothing bad should happen and it could "just work" > if tcc finds its stdarg.h instead of the musl one. > > Testing... I can compile with tcc a file calling printf, link > with musl and successfully run it. Nice! > > (Hmm, bits/alltypes defines ...va_list "instead of including stdarg.h", > I guess it could be made to include, guarded by some #if defined() ? No, this is the nasty gcc way which precludes the compiler from optimizing out multiple inclusions of the same header file, and which requires the libc headers and headers provided by the compiler to be aware of each other's implementation details, which is not really appropriate. > Besides this detail, it was apparently just a matter of wrapping tcc > with "-I \ > -D__DEFINED_va_list \ > -D__isoc_va_list=va_list \ > -D__DEFINED___isoc_va_list" > (this part is of course not of concern for musl, besides preserving the > possibility to externally define the types, in a compiler-specific stdarg.h) This is not supported usage with musl. > I think this is a correct approach which makes musl usable with > more compilers than otherwise. Only tcc, and tcc really just needs to be fixed in this regard. All the other compilers do it right already. It would not be hard to add the builtins and have them do the right thing, and this is essentially needed for x86_64 anyway -- the current approach of calling external functions is totally inappropriate since the generated .o files are not compatible with the ABI (which does not define such external functions) and cannot be successfully linked by non-tcc toolchains. Rich