[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140826195407.GG12888@brightrain.aerifal.cx>
Date: Tue, 26 Aug 2014 15:54:07 -0400
From: Rich Felker <dalias@...c.org>
To: u-igbb@...ey.se
Cc: musl@...ts.openwall.com
Subject: Re: compiling musl on x86_64 linux with pcc
On Tue, Aug 26, 2014 at 09:34:39PM +0200, u-igbb@...ey.se wrote:
> Hello Rich,
>
> On Mon, Aug 25, 2014 at 11:46:17AM -0400, Rich Felker wrote:
> > I have pcc 1.1.0.DEVEL 20130227 with pcc-libs-20130721 and it seems to
> > still work fine with current musl. Note that some fixes are needed for
> > pcc-libs:
> >
> > - You need to remove the broken csu files and replace them with
> > symlinks to the musl files.
>
> I do not even generate crt[01in].o in pcclibs and of course use
> the musl ones.
OK, just checking.
> > - 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.
> > - You need to add -fPIC to the CFLAGS for building libpcc or you get a
> > broken libpcc (containing textrels) that can't be used for building
> > libc.so and that's harmful for use with any other shared libs.
>
> I do.
>
> Anyway, the brokenness is present with both static and dynamic linking.
>
> (testing on i486-pc-linux-gnu)
>
> 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.
> > I just ran libc-test with libc.so built by pcc and confirmed that
> > there are no non-math regressions versus gcc-built libc.so. (I did not
> > check math in detail because there are lots of known math failures
> > that are not serious.)
> >
> > Let me know if you have any further questions about my setup.
>
> Is it possible to try pcc from 2014-08-24 in your environment?
>
> If it is hard, I can test the old versions instead (when I can, right now
> my time slice is over).
I can, but at at later time. I've got lots of other things I'm trying
to get done without adding pcc testing right now. So if you want to go
ahead and try it, go ahead.
> PS
> (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
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.
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.
