[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140112153309.GZ24286@brightrain.aerifal.cx>
Date: Sun, 12 Jan 2014 10:33:09 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Re: libgcc --disable-shared test case
On Sun, Jan 12, 2014 at 10:54:07AM +0100, John Spencer wrote:
> Rob Landley wrote:
> >On 01/11/14 17:55, John Spencer wrote:
> >>Rich Felker wrote:
> >>>The way to fix it is to find the conditional logic in the gcc build
> >>>system (I forget whether it's in configure, the Makefiles, or the
> >>>headers) that disables use of the visibility attribute when
> >>>--disable-shared is passed, and simply dummy it out so that visibility
> >>>is always used. At one point we discussed on IRC how this could be
> >>>fixed at the GCC level, so I could probably dig something out of IRC
> >>>logs if you want.
> >>
> >>that would be
> >>https://github.com/sabotage-linux/sabotage/blob/36661440192e2ec51531ea81c7866578010f3283/KEEP/gcc-454-libgcc_hidden.patch
> >>
> >
> >In 4.2 there is no libgcc/Makefile.in, instead there's a
> >mklibgcc.in generating the file. Given that it's generating a
> >value and assigning it to vis_hide a few lines earlier,
>
> @vis_hide@ is some external stuff that passes in all function names
> or so. the makefile has some logic depending on --disable-shared to
> either
> set vis_hide to all functions (@vis_hide@), or to nothing at all.
> this patch here just sets vis_hide to them all unconditionally
>
> >I have no idea if the suggested fix (trying to pass through a
> >value from autoconf?) is relevant to this version of the code.
> >
> >The real problem is I have no way to reproduce the failure yet.
> >The
>
>
> you can just build libc.so with the new compiler and if it has any
> undefined symbols in it, it's broken (readelf -a)
>
> a broken libc.so has stuff like this
> 2: 00000000 0 NOTYPE GLOBAL DEFAULT UND __muldc3
> 3: 00000000 0 NOTYPE GLOBAL DEFAULT UND __mulsc3
> 4: 00000000 0 NOTYPE GLOBAL DEFAULT UND __mulxc3
This is incorrect. You're describing what happened when you omitted
libgcc.a entirely from the link stage due to writing your own
config.mak by hand.
The sign of a broken libc.so (generated with broken libgcc.a) is
something like this in .symtab:
1948: 00052800 336 FUNC GLOBAL DEFAULT 6 __divdi3
Instead of GLOBAL, you should see LOCAL, indicating the symbol cannot
be used to satisfy undefined symbol references from other files. If
you see GLOBAL there, any applications built against this libc.so will
be broken; in particular, they will suddenly stop working when you
drop a correctly-built libc.so in its place.
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.
