headers
aep | 2 Jun 2012 00:18
Favicon
Gravatar

hm, libc crashes loading libc

with git 9ea20dcbaafe790bb034adadf05698088a2f9fab

this stuff scares me, so i'll just dump the relevant information, 
hoping someone knows what to do with it.

aep <at> nightbringer: /tmp echo "int main() {} " | musl-gcc -x c++ -
aep <at> nightbringer: /tmp ./a.out
zsh: segmentation fault  ./a.out

#0  find_sym (dso=0x7ffff7ff8a00, s=s <at> entry=0x7ffff7d7801d "__cgt", 
need_def=0) at src/ldso/dynlink.c:131
#1  0x00007ffff7d811a0 in do_relocs (dso=0x7ffff7ff8a00, 
strings=0x7ffff7d74d50 "", syms=0x7ffff7d6bdc8, rel_size=624, 
rel=0x7ffff7d786e8, base=0x7ffff7d69000 "\177ELF\002\001\001", 
stride=<optimized out>) at src/ldso/dynlink.c:161
#2  reloc_all (p=p <at> entry=0x7ffff7ff8a80) at src/ldso/dynlink.c:481
#3  0x00007ffff7d82667 in __dynlink (argc=<optimized out>, 
argv=<optimized out>) at src/ldso/dynlink.c:643
#4  0x00007ffff7d831e2 in _start () at src/ldso/x86_64/start.s:6
#5  0x0000000000000001 in ?? ()
#6  0x00007fffffffe77e in ?? ()
#7  0x0000000000000000 in ?? ()

reakpoint 1, reloc_all (p=p <at> entry=0x7ffff7ff8a80) at 
src/ldso/dynlink.c:472
472	{
(gdb) print p
$1 = (struct dso *) 0x7ffff7ff8a80
(gdb) p p->name
$3 = 0x7ffff7dcc012 "libc.so"
(Continue reading)

Permalink | Reply |
headers
aep | 2 Jun 2012 00:59
Favicon
Gravatar

Re: hm, libc crashes loading libc

On Sat, 02 Jun 2012 00:18:55 +0200, aep wrote:
> with git 9ea20dcbaafe790bb034adadf05698088a2f9fab
>
> this stuff scares me, so i'll just dump the relevant information,
> hoping someone knows what to do with it.

nsz also sayd this was relevant:
the symbol is a weak symbol which is supposed to be overriden by some 
vdso (he said dalias will know ;)

aep <at> nightbringer: ~/proj/musl nm /usr/local/musl/lib/libc.so | grep 
__cgt
000000000028f750 D __cgt

he made me remove that symbol from musl and we got further to a crash 
looking up __daylight.

aep <at> nightbringer: ~/proj/musl nm /usr/local/musl/lib/libc.so | grep 
__daylight
0000000000295d20 B __daylight

aep <at> nightbringer: ~/proj/musl readelf  --file-header --program-headers 
--sections --relocs --dynamic --notes /usr/local/musl/lib/libc.so
ELF Header:
   Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
   Class:                             ELF64
   Data:                              2's complement, little endian
   Version:                           1 (current)
   OS/ABI:                            UNIX - System V
   ABI Version:                       0
(Continue reading)

Permalink | Reply |
headers
Rich Felker | 2 Jun 2012 06:03

Re: hm, libc crashes loading libc

On Sat, Jun 02, 2012 at 12:18:55AM +0200, aep wrote:
> hashtab=0x0 sounds wrong, but how did it become zero?

By GCC 4.7 randomly reordering memory accesses with no rhyme or
reason. As discussed on IRC, this is GCC bug # 52734 and has nothing
to do with musl. Anyone experiencing it and unable to replace the
broken GCC can use the -fno-tree-tail-merge option as a workaround.

Rich
Permalink | Reply |
headers
aep | 2 Jun 2012 13:03
Favicon
Gravatar

Re: hm, libc crashes loading libc

On Sat, 2 Jun 2012 00:03:22 -0400, Rich Felker wrote:

> broken GCC can use the -fno-tree-tail-merge option as a workaround.

that didn't help me. trying clang right now.

it doesnt like the fistpq in src/math/x86_64/llrint.s though.
You might have forgotten to apply this to x86_64?
http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=0e195dfaa4902a73179f7ab296d47f01d3518ad3;hp=952700e8c32f7e81045cd01e1ecb3f7ca3f4c762
Permalink | Reply |
headers
aep | 2 Jun 2012 15:30
Favicon
Gravatar

Re: hm, libc crashes loading libc

On Sat, 2 Jun 2012 00:03:22 -0400, Rich Felker wrote:
> On Sat, Jun 02, 2012 at 12:18:55AM +0200, aep wrote:
>> hashtab=0x0 sounds wrong, but how did it become zero?

turns out the problem is that gcc 4.7.0 from archlinux adds 
--hash-style=gnu to ld, which musl cannot read.

this fixes it for me:

diff --git a/tools/musl-gcc.specs.sh b/tools/musl-gcc.specs.sh
index 5604685..9353706 100644
--- a/tools/musl-gcc.specs.sh
+++ b/tools/musl-gcc.specs.sh
 <at>  <at>  -25,7 +25,7  <at>  <at>  libgcc.a%s %:if-exists(libgcc_eh.a%s)
  %rename link old_link

  *link:
-%(old_link) -dynamic-linker $ldso -nostdlib
+%(old_link) -dynamic-linker $ldso -nostdlib --hash-style=sysv

  *esp_link:
Permalink | Reply |
headers
Rich Felker | 2 Jun 2012 22:32

Re: hm, libc crashes loading libc

On Sat, Jun 02, 2012 at 03:30:14PM +0200, aep wrote:
> On Sat, 2 Jun 2012 00:03:22 -0400, Rich Felker wrote:
> >On Sat, Jun 02, 2012 at 12:18:55AM +0200, aep wrote:
> >>hashtab=0x0 sounds wrong, but how did it become zero?
> 
> turns out the problem is that gcc 4.7.0 from archlinux adds
> --hash-style=gnu to ld, which musl cannot read.

I can look into how much work it would be to add GNU hash support, or
whether it's possible to support linear searching the symbol table
when the hash table is missing...

Rich
Permalink | Reply |
headers
aep | 2 Jun 2012 23:18
Favicon
Gravatar

Re: hm, libc crashes loading libc

On Sat, 2 Jun 2012 16:32:25 -0400, Rich Felker wrote:
> On Sat, Jun 02, 2012 at 03:30:14PM +0200, aep wrote:
>> turns out the problem is that gcc 4.7.0 from archlinux adds
>> --hash-style=gnu to ld, which musl cannot read.
>
> I can look into how much work it would be to add GNU hash support, or
> whether it's possible to support linear searching the symbol table
> when the hash table is missing...

does hash-style=gnu add any benefit for the target audience? I am 
noticing no speed difference for my small C program, but maybe it 
becomes interesting when C++  is added to the game.
Permalink | Reply |
headers
Rich Felker | 2 Jun 2012 23:41

Re: hm, libc crashes loading libc

On Sat, Jun 02, 2012 at 11:18:39PM +0200, aep wrote:
> On Sat, 2 Jun 2012 16:32:25 -0400, Rich Felker wrote:
> >On Sat, Jun 02, 2012 at 03:30:14PM +0200, aep wrote:
> >>turns out the problem is that gcc 4.7.0 from archlinux adds
> >>--hash-style=gnu to ld, which musl cannot read.
> >
> >I can look into how much work it would be to add GNU hash support, or
> >whether it's possible to support linear searching the symbol table
> >when the hash table is missing...
> 
> 
> does hash-style=gnu add any benefit for the target audience? I am
> noticing no speed difference for my small C program, but maybe it
> becomes interesting when C++  is added to the game.

Like most GNU junk, it's oriented towards the case where N->infinity.
For small values of N (the number of symbols), standard ELF hash table
is going to perform at least as well, maybe even better...

Basically, it was designed for speed up Firefox loading it's ugly .so
files at runtime. The correct fix, since they're all code that's used
by a SINGLE PROGRAM, is to get rid of the .so's and link them into the
main program, but for no rational reason, the Firefox developers
refuse to do this. I suspect it's because their build system is broken
and it's hard for them to test changes to these files without building
them as separate .so's...

Rich
(Continue reading)

Permalink | Reply |
headers
aep | 3 Jun 2012 13:27
Favicon
Gravatar

Re: hm, libc crashes loading libc

On Sat, 2 Jun 2012 17:41:03 -0400, Rich Felker wrote:

> Like most GNU junk, it's oriented towards the case where N->infinity.

C++ is broken in that way, but it's a reality thing. You can't just 
make C++ go away.

I think i will run into very _long_ symbol names with clay, does 
gnuhash stuff help me there or is it just good for large amounts of 
symbols?

> I suspect it's because their build system is broken and it's hard for 
> them to test changes to these files without building them as separate 
> .so's...

Someone prof wrote a book on how to design your stuff in a modular way, 
and all the fresh university students remembered was "have a lot of 
DSO's".
Now we've got a lot of non modular DSOs. congratulations. Same with 
dbus today.
Permalink | Reply |

Gmane