Re: compiling musl on x86_64 linux with pcc

[u-igbb@aetey.se]

On Tue, Aug 26, 2014 at 03:54:07PM -0400, Rich Felker wrote:
> > > - You need to add __attribute__((__visibility__("hidden"))) to all
> > >   external functions in libpcc.
> > 
> > This does not seem to make any difference
> 
> It does. Failure to fix this will result in these symbols becoming
> part of the public ABI of any .so file that pulls them in, and will
> thereby prevent them from being linked into apps that use the .so file
> (since the app will already have its need for them satisfied). If the
> .so file later changes such that it no longer needs the functions (or
> if it's upgraded to a version that's correctly linked with a libpcc.a
> where these symbols are hidden, then such apps will break.
> 
> > (and probably would not 
> > be noticeable with simple tests anyway?).
> 
> I agree that it would not be noticed right away, but it is important.

I see, I meant only that this change did not improve the situation, not
that it was unnecessary. The compiler-related libraries are logically
just a part of the generated code which is chosen not to be inlined, iow
either the ABI to them should be stable (and the library available as
both static and shared) or the referred funtions should be implicitly
inserted into each object file. I guess the "hidden" magic approximates
this well enough (ensuring a single copy of the statically linked
functions in dynamically linked executables).

> > I narrowed down what looks broken:
> > *printf() with "%something" seems to pick wrong arguments,
> > iow it looks like malfunctioning variadic args. (?)
> 
> I have not seen anything like that happening.

Ok.

> > (this variadic business reminds me again that stdarg.h should be provided
> > by the compiler who knows what it can do to the generated functions and
> > what it must do with the public ones - not by the library which can be
> > used with different compilers and should not boldly assume the level of
> > their intelligence)
> 
> This is unrelatd. pcc's version would be exactly the same thing, and

Yes it is more general but when I thought about troubleshooting I realized
I have to account for what the library / the compiler believe about the
variadic arguments and whether these views are compatible.

> in fact, as I explained before, there is only one correct
> implementation: builtin functions like __builtin_va_arg, etc. but
> possibly with gratuitously different names or argument orders. In any
> case there is no way to simply "let the compiler do it" because
> certain other headers need to access or expose the va_list type, and
> doing this with a compiler-provided stdarg.h requires knowledge of the
> compiler versions internals in the libc headers, which is much worse
> than the current situation.

The current situation is (!) actually using knowledge of the compiler
in the library headers (checking for gcc version, as you noted when we
were talking about tcc), which shouldn't be needed if the library would
skip referring to the intimate knowledge of those details.

I am possibly not realizing some crucial bit but I do not see why the
implementation of stdarg.h must be the business of the library. If the
compiler *building* the library wants the va_arg to be __builtin_va_arg,
then you get the same functionality / efficiency as now, otherwise you
get a less efficient but still fully compatible library, don't you?
A compiler used *together* with the library may lack the builtins but it
still can be fully compatible even if in some situations less efficient.

No compiler (if ABI-compatible) is allowed to produce code unusable when
linked to code compiled by another compiler. How allowing the compiler
to pick its own stdarg.h would lead to a less efficient code than otherwise?

Rune