[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140815155656.GQ12888@brightrain.aerifal.cx>
Date: Fri, 15 Aug 2014 11:56:56 -0400
From: Rich Felker <dalias@...c.org>
To: u-igbb@...ey.se
Cc: musl@...ts.openwall.com
Subject: Re: va_list (was: compiling musl on x86_64 linux with
pcc)
On Fri, Aug 15, 2014 at 05:07:23PM +0200, u-igbb@...ey.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<where-the-tcc-stdarg.h-alone-lives> \
> -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
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.
