musl built with pcc yields segfaults in dynlink.c

musl built with pcc yields segfaults in dynlink.c

[Isaac Dunham]

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

Hello,
I'm trying to get a pcc-built libc.so that works.
With the latest PCC, musl builds (lib/libc.so) and the result will display
the proper messages if run from the command line without arguments.
However, if I try to run a program with it 
(even via -Wl,-dynamic-linker,`pwd`/lib/libc.so), I get a segfault
in src/ldso/dynlink.c:
(gdb) where
#0  sysv_hash (s0=0x0, s0=0x0) at src/ldso/dynlink.c:177
#1  0xb7f6f747 in find_sym (dso=0xbffffb18, rel=0xb7ffe1d4 <.L1502>, 
    rel_size=<unknown type>, stride=<unknown type>, dso=0xbffffb18, 
    rel=0xb7ffe1d4 <.L1502>, rel_size=<unknown type>, stride=<unknown type>)
    at src/ldso/dynlink.c:251
    #2  0xb7f6f916 in do_relocs () at src/ldso/dynlink.c:308
    Backtrace stopped: frame did not save the PC

I'm using Alpine Linux edge, recently updated, with linux-vanilla.

Compiling pcc:
#from pcc cvs tip
./configure --prefix=/usr --build=i486-alpine-linux-musl \
--target=i486-alpine-linux-musl --enable-tls --enable-native
make
make install
#from pcc-libs cvs tip
cp ../pcc/config.guess ../pcc/config.sub ./
cd libpcc/
for f in cmpdi2.c divdi3.c fixdfdi.c fixsfdi.c fixunsdfdi.c fixunssfdi.c \
	floatdidf.c floatdisf.c floatunsdidf.c moddi3.c muldi3.c negdi2.c \
	qdivrem.c ucmpdi2.c udivdi3.c umoddi3.c cxmuldiv.c ashldi3.c ashrdi3.c \
	lshrdi3.c _alloca.c unwind.c ssp.c
    do hideintern.sed -i $f
    done

export CFLAGS=-Os -fPIC
./configure --prefix=/usr --build=i486-alpine-linux-musl \
	--target=i486-alpine-linux-musl
make
make install

Compiling musl:
#from git tip
CC=pcc ./configure --target=i486 --disable-static
#add -g to CFLAGS, probably enable-debug is better
make

Testing musl:
gcc -Wl,-dynamic-linker,`pwd`/lib/libc.so test.c
./a.out


hideintern.sed is how I'm adding the 
__attribute__((__visibility__("hidden")))
stuff to libpcc.a.


What would be most helpful for debugging?

Thanks,
Isaac Dunham


[-- Attachment #2: hideintern.sed --]
[-- Type: text/plain, Size: 538 bytes --]

#!/bin/sed -f
# Hide functions with leading underscores.
# Used for patching the pcc-libs tree.
# Since we need to patch the line before the one that matches a pattern,
# we must use the hold space.
# Method:
#  hold/delete line one
#  if this line matches, swap for last line, modify pattern space, swap back
#  swap with last line, so we print it and save this line for next
#  at the end, print the prior line, then swap it for the last line
1{h;d}
/^_.*(.*)$/{x;s/^\(.*\)$/__attribute__((__visibility__("hidden"))) \1/;x}
2,$x
${p;x}

Re: musl built with pcc yields segfaults in dynlink.c

[Rich Felker]

On Mon, Jan 05, 2015 at 11:48:50PM -0800, Isaac Dunham wrote:
> Hello,
> I'm trying to get a pcc-built libc.so that works.
> With the latest PCC, musl builds (lib/libc.so) and the result will display
> the proper messages if run from the command line without arguments.
> However, if I try to run a program with it 
> (even via -Wl,-dynamic-linker,`pwd`/lib/libc.so), I get a segfault
> in src/ldso/dynlink.c:
> (gdb) where
> #0  sysv_hash (s0=0x0, s0=0x0) at src/ldso/dynlink.c:177
> #1  0xb7f6f747 in find_sym (dso=0xbffffb18, rel=0xb7ffe1d4 <.L1502>, 
>     rel_size=<unknown type>, stride=<unknown type>, dso=0xbffffb18, 
>     rel=0xb7ffe1d4 <.L1502>, rel_size=<unknown type>, stride=<unknown type>)
>     at src/ldso/dynlink.c:251
>     #2  0xb7f6f916 in do_relocs () at src/ldso/dynlink.c:308
>     Backtrace stopped: frame did not save the PC
> 
> I'm using Alpine Linux edge, recently updated, with linux-vanilla.

It would be helpful to see the readelf -a output for libc.so and the
binary using it, and whatever information gdb can give on the value of
local vars at each of the above call frames.

Rich

Re: musl built with pcc yields segfaults in dynlink.c

[Isaac Dunham]

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

On Tue, Jan 06, 2015 at 03:49:24PM -0500, Rich Felker wrote:
> On Mon, Jan 05, 2015 at 11:48:50PM -0800, Isaac Dunham wrote:
> > Hello,
> > I'm trying to get a pcc-built libc.so that works.
> > With the latest PCC, musl builds (lib/libc.so) and the result will display
> > the proper messages if run from the command line without arguments.
> > However, if I try to run a program with it 
> > (even via -Wl,-dynamic-linker,`pwd`/lib/libc.so), I get a segfault
> > in src/ldso/dynlink.c:
> > (gdb) where
> > #0  sysv_hash (s0=0x0, s0=0x0) at src/ldso/dynlink.c:177
> > #1  0xb7f6f747 in find_sym (dso=0xbffffb18, rel=0xb7ffe1d4 <.L1502>, 
> >     rel_size=<unknown type>, stride=<unknown type>, dso=0xbffffb18, 
> >     rel=0xb7ffe1d4 <.L1502>, rel_size=<unknown type>, stride=<unknown type>)
> >     at src/ldso/dynlink.c:251
> >     #2  0xb7f6f916 in do_relocs () at src/ldso/dynlink.c:308
> >     Backtrace stopped: frame did not save the PC
> > 
> > I'm using Alpine Linux edge, recently updated, with linux-vanilla.
> 
> It would be helpful to see the readelf -a output for libc.so and the
> binary using it, and whatever information gdb can give on the value of
> local vars at each of the above call frames.

Attaching a tar.xz containing the output of:
- readelf -a lib/libc.so:	libc-pcc.readelf
- readelf -a a.out:		argvname.readelf
- echo -e 'run\nwhere\nbt full' |gdb ./a.out:	argvname.gdb
 (which is substantially similar to the output for "lib/libc.so ./a.out")
- and the source for a.out:	argvname.c

It's 51k, so I'm hoping it gets through.

Thanks,
Isaac Dunham

[-- Attachment #2: pcclibc.tar.xz --]
[-- Type: application/octet-stream, Size: 53072 bytes --]

Re: musl built with pcc yields segfaults in dynlink.c

[Rich Felker]

On Tue, Jan 06, 2015 at 02:56:50PM -0800, Isaac Dunham wrote:
> On Tue, Jan 06, 2015 at 03:49:24PM -0500, Rich Felker wrote:
> > On Mon, Jan 05, 2015 at 11:48:50PM -0800, Isaac Dunham wrote:
> > > Hello,
> > > I'm trying to get a pcc-built libc.so that works.
> > > With the latest PCC, musl builds (lib/libc.so) and the result will display
> > > the proper messages if run from the command line without arguments.
> > > However, if I try to run a program with it 
> > > (even via -Wl,-dynamic-linker,`pwd`/lib/libc.so), I get a segfault
> > > in src/ldso/dynlink.c:
> > > (gdb) where
> > > #0  sysv_hash (s0=0x0, s0=0x0) at src/ldso/dynlink.c:177
> > > #1  0xb7f6f747 in find_sym (dso=0xbffffb18, rel=0xb7ffe1d4 <.L1502>, 
> > >     rel_size=<unknown type>, stride=<unknown type>, dso=0xbffffb18, 
> > >     rel=0xb7ffe1d4 <.L1502>, rel_size=<unknown type>, stride=<unknown type>)
> > >     at src/ldso/dynlink.c:251
> > >     #2  0xb7f6f916 in do_relocs () at src/ldso/dynlink.c:308
> > >     Backtrace stopped: frame did not save the PC
> > > 
> > > I'm using Alpine Linux edge, recently updated, with linux-vanilla.
> > 
> > It would be helpful to see the readelf -a output for libc.so and the
> > binary using it, and whatever information gdb can give on the value of
> > local vars at each of the above call frames.
> 
> Attaching a tar.xz containing the output of:
> - readelf -a lib/libc.so:	libc-pcc.readelf
> - readelf -a a.out:		argvname.readelf
> - echo -e 'run\nwhere\nbt full' |gdb ./a.out:	argvname.gdb
>  (which is substantially similar to the output for "lib/libc.so ./a.out")
> - and the source for a.out:	argvname.c
> 
> It's 51k, so I'm hoping it gets through.

It came through fine, but I suspect the debug info is bogus. The
values being shown don't seem to make sense. It might help more to
show the disassembly at eip and the value of all registers, or to post
the binaries somewhere I could download and analyze them. I looked at
the readelf outputs and didn't see any invalid relocs immediately, so
I'm not sure what's happening.

Rich

Re: musl built with pcc yields segfaults in dynlink.c

[Isaac Dunham]

On Tue, Jan 06, 2015 at 07:53:57PM -0500, Rich Felker wrote:
> On Tue, Jan 06, 2015 at 02:56:50PM -0800, Isaac Dunham wrote:
> > On Tue, Jan 06, 2015 at 03:49:24PM -0500, Rich Felker wrote:
> > > On Mon, Jan 05, 2015 at 11:48:50PM -0800, Isaac Dunham wrote:
> > > > Hello,
> > > > I'm trying to get a pcc-built libc.so that works.
> > > > With the latest PCC, musl builds (lib/libc.so) and the result will display
> > > > the proper messages if run from the command line without arguments.
> > > > However, if I try to run a program with it 
> > > > (even via -Wl,-dynamic-linker,`pwd`/lib/libc.so), I get a segfault
> > > > in src/ldso/dynlink.c:
> > > > (gdb) where
> > > > #0  sysv_hash (s0=0x0, s0=0x0) at src/ldso/dynlink.c:177
> > > > #1  0xb7f6f747 in find_sym (dso=0xbffffb18, rel=0xb7ffe1d4 <.L1502>, 
> > > >     rel_size=<unknown type>, stride=<unknown type>, dso=0xbffffb18, 
> > > >     rel=0xb7ffe1d4 <.L1502>, rel_size=<unknown type>, stride=<unknown type>)
> > > >     at src/ldso/dynlink.c:251
> > > >     #2  0xb7f6f916 in do_relocs () at src/ldso/dynlink.c:308
> > > >     Backtrace stopped: frame did not save the PC
> > > > 
> > > > I'm using Alpine Linux edge, recently updated, with linux-vanilla.
> > > 
> > > It would be helpful to see the readelf -a output for libc.so and the
> > > binary using it, and whatever information gdb can give on the value of
> > > local vars at each of the above call frames.
> > 
> > Attaching a tar.xz containing the output of:
> > - readelf -a lib/libc.so:	libc-pcc.readelf
> > - readelf -a a.out:		argvname.readelf
> > - echo -e 'run\nwhere\nbt full' |gdb ./a.out:	argvname.gdb
> >  (which is substantially similar to the output for "lib/libc.so ./a.out")
> > - and the source for a.out:	argvname.c
> > 
> > It's 51k, so I'm hoping it gets through.
> 
> It came through fine, but I suspect the debug info is bogus. The
> values being shown don't seem to make sense. It might help more to
> show the disassembly at eip and the value of all registers, or to post
> the binaries somewhere I could download and analyze them. I looked at
> the readelf outputs and didn't see any invalid relocs immediately, so
> I'm not sure what's happening.

https://www.dropbox.com/s/gfakdgdg4i1n85j/libc.tar.xz?dl=1

As far as I can tell, there's no reason to use the particular program
I'm testing with; it just happens to be a trivial program I had.


Thanks,
Isaac Dunham

Re: musl built with pcc yields segfaults in dynlink.c

[stephen Turner]

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

Whats the -fpic setting for and is that the trigger of the issue? Google
has zip on -fpic.

[-- Attachment #2: Type: text/html, Size: 108 bytes --]

Re: musl built with pcc yields segfaults in dynlink.c

[Rich Felker]

On Tue, Jan 06, 2015 at 06:01:10PM -0800, Isaac Dunham wrote:
> On Tue, Jan 06, 2015 at 07:53:57PM -0500, Rich Felker wrote:
> > On Tue, Jan 06, 2015 at 02:56:50PM -0800, Isaac Dunham wrote:
> > > On Tue, Jan 06, 2015 at 03:49:24PM -0500, Rich Felker wrote:
> > > > On Mon, Jan 05, 2015 at 11:48:50PM -0800, Isaac Dunham wrote:
> > > > > Hello,
> > > > > I'm trying to get a pcc-built libc.so that works.
> > > > > With the latest PCC, musl builds (lib/libc.so) and the result will display
> > > > > the proper messages if run from the command line without arguments.
> > > > > However, if I try to run a program with it 
> > > > > (even via -Wl,-dynamic-linker,`pwd`/lib/libc.so), I get a segfault
> > > > > in src/ldso/dynlink.c:
> > > > > (gdb) where
> > > > > #0  sysv_hash (s0=0x0, s0=0x0) at src/ldso/dynlink.c:177
> > > > > #1  0xb7f6f747 in find_sym (dso=0xbffffb18, rel=0xb7ffe1d4 <.L1502>, 
> > > > >     rel_size=<unknown type>, stride=<unknown type>, dso=0xbffffb18, 
> > > > >     rel=0xb7ffe1d4 <.L1502>, rel_size=<unknown type>, stride=<unknown type>)
> > > > >     at src/ldso/dynlink.c:251
> > > > >     #2  0xb7f6f916 in do_relocs () at src/ldso/dynlink.c:308
> > > > >     Backtrace stopped: frame did not save the PC
> > > > > 
> > > > > I'm using Alpine Linux edge, recently updated, with linux-vanilla.
> > > > 
> > > > It would be helpful to see the readelf -a output for libc.so and the
> > > > binary using it, and whatever information gdb can give on the value of
> > > > local vars at each of the above call frames.
> > > 
> > > Attaching a tar.xz containing the output of:
> > > - readelf -a lib/libc.so:	libc-pcc.readelf
> > > - readelf -a a.out:		argvname.readelf
> > > - echo -e 'run\nwhere\nbt full' |gdb ./a.out:	argvname.gdb
> > >  (which is substantially similar to the output for "lib/libc.so ./a.out")
> > > - and the source for a.out:	argvname.c
> > > 
> > > It's 51k, so I'm hoping it gets through.
> > 
> > It came through fine, but I suspect the debug info is bogus. The
> > values being shown don't seem to make sense. It might help more to
> > show the disassembly at eip and the value of all registers, or to post
> > the binaries somewhere I could download and analyze them. I looked at
> > the readelf outputs and didn't see any invalid relocs immediately, so
> > I'm not sure what's happening.
> 
> https://www.dropbox.com/s/gfakdgdg4i1n85j/libc.tar.xz?dl=1
> 
> As far as I can tell, there's no reason to use the particular program
> I'm testing with; it just happens to be a trivial program I had.

So far I haven't been able to make any sense of the crash. The debug
info produced by pcc is utter nonsense, or at least not what gdb is
expecting; the symbolic information it's printing is all wrong, and
trying to set breakpoints even crashes my gdb. The size of the
do_relocs stack frame looks wrong too; the arguments for find_sym and
subsequent stuff on the stack looks closer to do_relocs' return
address than it should be.

I wonder if pcc is generating bogus code for functions which return
structures...

Rich

Re: musl built with pcc yields segfaults in dynlink.c

[stephen Turner]

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

> I wonder if pcc is generating bogus code for functions which return
> structures...
>
> Rich

Didnt they recently made a code change to x86?

[-- Attachment #2: Type: text/html, Size: 211 bytes --]

Re: musl built with pcc yields segfaults in dynlink.c

[Rich Felker]

On Wed, Jan 07, 2015 at 12:48:13AM -0500, stephen Turner wrote:
> > I wonder if pcc is generating bogus code for functions which return
> > structures...
> >
> > Rich
> 
> Didnt they recently made a code change to x86?

Not sure. It would be a good idea to try somewhat older versions and
see when it broke. I still have pcc 1.1.0.DEVEL 20130227 and the
problem does not exist in that version, but of course that's pretty
old.

Rich

Re: musl built with pcc yields segfaults in dynlink.c

[stephen Turner]

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

On Jan 7, 2015 9:17 PM, "Rich Felker" <dalias@libc.org> wrote:
>
> On Wed, Jan 07, 2015 at 12:48:13AM -0500, stephen Turner wrote:
> > > I wonder if pcc is generating bogus code for functions which return
> > > structures...
> > >
> > > Rich
> >
> > Didnt they recently made a code change to x86?
>
> Not sure. It would be a good idea to try somewhat older versions and
> see when it broke. I still have pcc 1.1.0.DEVEL 20130227 and the
> problem does not exist in that version, but of course that's pretty
> old.
>
> Rich

Yea they started making the major changes that impact all platforms around
12/20/2014
On twards the new year. Changes to the core programs under the cc sub dir.
And the platform I was remembering was 8086 i86 what ever that is.

[-- Attachment #2: Type: text/html, Size: 986 bytes --]