Re: va_list (was: [musl] compiling musl on x86_64 linux with pcc)

[u-igbb@aetey.se]

On Fri, Aug 15, 2014 at 11:56:56AM -0400, Rich Felker wrote:
> > 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.

Fine with me, it is just a matter to teach tcc to implicitly include its
stdarg.h.

> > 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.

Surely, I am using the internal details which is bad - it would be
nice if musl would allow a cleaner way of doing a corresponding
hook.

> > 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

This of course would be the best solution - but tcc is as it is, with
the limitations and the nice properties. I'd like to be able to use it,
or if anybody hacks a differently nice / differently bad compiler,
to be able to use it too.

This does not look like putting any constraints on musl efficienly or
correctness - the only thing which is necessary is a (possibly even
musl-version-dependent) way to skip/replace the va-definitions. I think
it is no practical problem, good enough, unless you decide to radically
change the implementation.

> 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.

Hmm. Yes that's right (non-tcc-"aware" toolchains that is - no problem
to arrange non-tcc linking to work, but you can not give such object files
to others to link...). To be compatible, a compiler-specific implementation
must be effectively inlined in every .o file, which tcc does not do
(and which builtins of course do, but they are nevertheless not the only
valid solution - even though they seem to be a good one :)

Thanks for clearing the matter!

Rune