[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140815150722.GC5170@example.net>
Date: Fri, 15 Aug 2014 17:07:23 +0200
From: u-igbb@...ey.se
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: va_list (was: compiling musl on x86_64 linux with
pcc)
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<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)
I think this is a correct approach which makes musl usable with
more compilers than otherwise.
Regards,
Rune
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.
