Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 7 Jan 2015 00:33:16 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: musl built with pcc yields segfaults in dynlink.c

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

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.