From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5863 Path: news.gmane.org!not-for-mail From: u-igbb@aetey.se 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 17:07:23 +0200 Message-ID: <20140815150722.GC5170@example.net> References: <20140813091843.GD5170@example.net> <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> 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 1408115277 28644 80.91.229.3 (15 Aug 2014 15:07:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Aug 2014 15:07:57 +0000 (UTC) Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-5869-gllmg-musl=m.gmane.org@lists.openwall.com Fri Aug 15 17:07:52 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 1XIJ6d-0005q1-RK for gllmg-musl@plane.gmane.org; Fri, 15 Aug 2014 17:07:51 +0200 Original-Received: (qmail 30161 invoked by uid 550); 15 Aug 2014 15:07:51 -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 30153 invoked from network); 15 Aug 2014 15:07:51 -0000 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Received-SPF: none receiver=mailfe02.swip.net; client-ip=96.47.226.21; envelope-from=u-igbb@aetey.se Content-Disposition: inline In-Reply-To: <20140815134434.GP12888@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:5863 Archived-At: 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() ? 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) I think this is a correct approach which makes musl usable with more compilers than otherwise. Regards, Rune