Re: libgcc --disable-shared test case

Re: libgcc --disable-shared test case

[Rob Landley]

On 10/17/2013 01:09:13 AM, Rich Felker wrote:
> On i386 or any arch where libgcc functions are needed for 64-bit
> division, the following should reproduce the failure if libgcc was
> built with --disable-shared (which disables visibility):
> 
> gcc -O2 -shared -o libfoo.so lib_v1.c
> gcc -O2 main.c ./libfoo.so
> ./a.out # ok
> gcc -O2 -shared -o libfoo.so lib_v2.c
> ./a.out # fails with symbol errors
> 
> Rich

lib_v1.c:
   long long foo(long long x) { return x/10; }

lib_v2.c:
   long long foo(long long x) { return x/16; }

main.c:
   #include <stdio.h>
   extern long long foo(long long);
   int main() { printf("%lld\n", foo(100)/10); }

Ok, I just tested this again. With lib_v1.c, the one built with my  
simple-cross-compiler toolchain printed 1, and the lib_v2.c printed 0.  
(I believe you said the error was a link failure?)

I had to copy the resulting a.out and libfoo.so into  
simple-root-filesystem (which was built with the simple cross compiler  
and doesn't contain a native compiler) to run it in a chroot because  
the host hasn't got uClibc libraries installed in it, hence no  
libc.so.0 for the dynamic link...

Looks like my toolchain doesn't exhibit this behavior? (Not after I  
hacked the hell out of the libgcc.a build, anyway...)

(I'm sure I tested this before, but didn't write the result down.  
There's a reason I blog to myself so much when I'm not buried by  
$DAYJOB...)

Rob

Re: Re: libgcc --disable-shared test case

[Rich Felker]

On Sat, Jan 11, 2014 at 11:40:32AM -0600, Rob Landley wrote:
> On 10/17/2013 01:09:13 AM, Rich Felker wrote:
> >On i386 or any arch where libgcc functions are needed for 64-bit
> >division, the following should reproduce the failure if libgcc was
> >built with --disable-shared (which disables visibility):
> >
> >gcc -O2 -shared -o libfoo.so lib_v1.c
> >gcc -O2 main.c ./libfoo.so
> >./a.out # ok
> >gcc -O2 -shared -o libfoo.so lib_v2.c
> >./a.out # fails with symbol errors
> >
> >Rich
> 
> lib_v1.c:
>   long long foo(long long x) { return x/10; }
> 
> lib_v2.c:
>   long long foo(long long x) { return x/16; }
> 
> main.c:
>   #include <stdio.h>
>   extern long long foo(long long);
>   int main() { printf("%lld\n", foo(100)/10); }
> 
> Ok, I just tested this again. With lib_v1.c, the one built with my
> simple-cross-compiler toolchain printed 1, and the lib_v2.c printed
> 0. (I believe you said the error was a link failure?)
> 
> I had to copy the resulting a.out and libfoo.so into
> simple-root-filesystem (which was built with the simple cross
> compiler and doesn't contain a native compiler) to run it in a
> chroot because the host hasn't got uClibc libraries installed in it,
> hence no libc.so.0 for the dynamic link...
> 
> Looks like my toolchain doesn't exhibit this behavior? (Not after I
> hacked the hell out of the libgcc.a build, anyway...)

What arch? I would expect this to show up on i386 but not x86_64,
since the latter has native division and libgcc functions won't be
needed. It could also be an issue of -O level if gcc decided to use
long division instead of bitshift to implement /16. Or it might be
something completely different.

If you could share the two versions of libfoo.so, a.out, and maybe
even libgcc.a, I can probably figure out what's going on.

Rich

Re: Re: libgcc --disable-shared test case

[Rob Landley]

[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]

On 01/11/14 15:51, Rich Felker wrote:
> On Sat, Jan 11, 2014 at 11:40:32AM -0600, Rob Landley wrote:
>> Looks like my toolchain doesn't exhibit this behavior? (Not after I
>> hacked the hell out of the libgcc.a build, anyway...)
>
> What arch?

i686.

> I would expect this to show up on i386 but not x86_64,
> since the latter has native division and libgcc functions won't be
> needed. It could also be an issue of -O level if gcc decided to use
> long division instead of bitshift to implement /16.

It was -O2 because your email said -O2. Only thing that changed in the 
command line(s) was the compiler binary path/name.

> Or it might be something completely different.
>
> If you could share the two versions of libfoo.so, a.out, and maybe
> even libgcc.a, I can probably figure out what's going on.

Tarball of the newly built stuff attached, the other stuff should be at 
http://landley.net/simple-root-filesystem-i686.tar.bz2 (which isn't the 
release version because I made sure this one _wasn't_ built from a stage 
2 cross compiler. This is from an aboriginal build that didn't do a 
stage 2 cross compiler, but built everything with the "simple" cross 
compiler.)

> Rich

Rob

[-- Attachment #2: test.tar.bz2 --]
[-- Type: application/x-bzip, Size: 7051 bytes --]

Re: Re: libgcc --disable-shared test case

[Rich Felker]

On Sat, Jan 11, 2014 at 04:04:25PM -0600, Rob Landley wrote:
> >If you could share the two versions of libfoo.so, a.out, and maybe
> >even libgcc.a, I can probably figure out what's going on.
> 
> Tarball of the newly built stuff attached, the other stuff should be
> at http://landley.net/simple-root-filesystem-i686.tar.bz2 (which
> isn't the release version because I made sure this one _wasn't_
> built from a stage 2 cross compiler. This is from an aboriginal
> build that didn't do a stage 2 cross compiler, but built everything
> with the "simple" cross compiler.)

OK, here's my analysis. a.out does not contain __divdi3, which it
should, but instead contains an undefined reference to it. libfoo1.so
contains a definition for __divdi3, and libfoo2.so does not. So far,
this is all exactly how I expected the linking against a broken
libgcc.a to manifest.

So, why does it "work"? Because your uclibc was also built against
this broken libgcc.a, and thus exports __divdi3 and whatever subset of
the libgcc symbols *happened* to get used by code in libc. If you
replace it with a properly built uclibc libc.so.0 (i.e. one built with
a gcc toolchain that was not using --disable-shared), your a.out will
definitely stop working. If this weren't troubling enough, it could in
principle just stop working as a result of internal changes to uclibc.
(This is unlikely with __divdi3, whose use is extremely common, but it
could easily happen with the other weird libgcc functions used for
dispatching switch statements on long long, floating point to long
long conversions, etc.)

If you want to see the issue manifest without replacing uclibc, the
easiest way would be to check *which* libgcc symbols got pulled into
libc.so.0, then modify the test code for libfoo.so to use a feature
that will pull in one of the libgcc symbols not in libc.

Rich

Re: Re: libgcc --disable-shared test case

[Rob Landley]

On 01/11/14 16:23, Rich Felker wrote:
> On Sat, Jan 11, 2014 at 04:04:25PM -0600, Rob Landley wrote:
> If you want to see the issue manifest without replacing uclibc, the
> easiest way would be to check *which* libgcc symbols got pulled into
> libc.so.0, then modify the test code for libfoo.so to use a feature
> that will pull in one of the libgcc symbols not in libc.
>
> Rich

My goal is to make it work, with a brick if necessary. This includes 
making it all work under musl.

I'm already patching the libgcc.a build to produce libgcc_eh.a at 
inappropriate times and shoehorning in symbols that problably shouldn't 
go in there. (And then ccwrap is shoehorning in libgcc_eh.a when it 
pulls in libgcc.a.)

My position on the --disable-shared gcc being subtly broken is that it's 
a bug in gcc I should fix (at least until replacing one more FSF project 
with something better). Generally if I can reproduce a problem and get 
enough time to work on it, I can fix it. I just wanted to make sure that 
my failure to reproduce this issue wasn't because I subtly screwed up. :)

Rob

Re: Re: libgcc --disable-shared test case

[Rich Felker]

On Sat, Jan 11, 2014 at 04:38:36PM -0600, Rob Landley wrote:
> On 01/11/14 16:23, Rich Felker wrote:
> >On Sat, Jan 11, 2014 at 04:04:25PM -0600, Rob Landley wrote:
> >If you want to see the issue manifest without replacing uclibc, the
> >easiest way would be to check *which* libgcc symbols got pulled into
> >libc.so.0, then modify the test code for libfoo.so to use a feature
> >that will pull in one of the libgcc symbols not in libc.
> >
> >Rich
> 
> My goal is to make it work, with a brick if necessary. This includes
> making it all work under musl.
> 
> I'm already patching the libgcc.a build to produce libgcc_eh.a at
> inappropriate times and shoehorning in symbols that problably
> shouldn't go in there. (And then ccwrap is shoehorning in
> libgcc_eh.a when it pulls in libgcc.a.)
> 
> My position on the --disable-shared gcc being subtly broken is that
> it's a bug in gcc I should fix (at least until replacing one more
> FSF project with something better). Generally if I can reproduce a
> problem and get enough time to work on it, I can fix it. I just
> wanted to make sure that my failure to reproduce this issue wasn't
> because I subtly screwed up. :)

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.

Rich

Re: Re: libgcc --disable-shared test case

[Rob Landley]

On 01/11/14 16:45, 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.

I'm not worried about figuring out how to beat another piece of brain 
damage out of gcc (by removing code, always by _removing_ something they 
shouldn't have done in the first place).

It's fixing a problem I can't reproduce that's the hard part. Hence the 
request for a test case...

Rob

Re: Re: libgcc --disable-shared test case

[John Spencer]

Rich Felker wrote:
> On Sat, Jan 11, 2014 at 04:38:36PM -0600, Rob Landley wrote:
>> On 01/11/14 16:23, Rich Felker wrote:
>>> On Sat, Jan 11, 2014 at 04:04:25PM -0600, Rob Landley wrote:
>>> If you want to see the issue manifest without replacing uclibc, the
>>> easiest way would be to check *which* libgcc symbols got pulled into
>>> libc.so.0, then modify the test code for libfoo.so to use a feature
>>> that will pull in one of the libgcc symbols not in libc.
>>>
>>> Rich
>> My goal is to make it work, with a brick if necessary. This includes
>> making it all work under musl.
>>
>> I'm already patching the libgcc.a build to produce libgcc_eh.a at
>> inappropriate times and shoehorning in symbols that problably
>> shouldn't go in there. (And then ccwrap is shoehorning in
>> libgcc_eh.a when it pulls in libgcc.a.)
>>
>> My position on the --disable-shared gcc being subtly broken is that
>> it's a bug in gcc I should fix (at least until replacing one more
>> FSF project with something better). Generally if I can reproduce a
>> problem and get enough time to work on it, I can fix it. I just
>> wanted to make sure that my failure to reproduce this issue wasn't
>> because I subtly screwed up. :)
> 
> 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

> 
> Rich
> 

Re: Re: libgcc --disable-shared test case

[Rob Landley]

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, 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 
comment that it occurs building musl for mips seems useful, I'll try 
that. But it's kinda hard to fix a failure I've never seen fail...

Rob

Re: Re: libgcc --disable-shared test case

[John Spencer]

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


> comment that it occurs building musl for mips seems useful, I'll try 
> that. But it's kinda hard to fix a failure I've never seen fail...
> 
> Rob
> 

Re: Re: libgcc --disable-shared test case

[Rich Felker]

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