mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: musl built with pcc yields segfaults in dynlink.c
Date: Wed, 7 Jan 2015 00:33:16 -0500	[thread overview]
Message-ID: <20150107053316.GO4574@brightrain.aerifal.cx> (raw)
In-Reply-To: <20150107020107.GA2336@newbook>

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


  parent reply	other threads:[~2015-01-07  5:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-06  7:48 Isaac Dunham
2015-01-06 20:49 ` Rich Felker
2015-01-06 22:56   ` Isaac Dunham
2015-01-07  0:53     ` Rich Felker
2015-01-07  2:01       ` Isaac Dunham
2015-01-07  5:20         ` stephen Turner
2015-01-07  5:33         ` Rich Felker [this message]
2015-01-07  5:48           ` stephen Turner
2015-01-08  2:16             ` Rich Felker
2015-01-08  3:56               ` stephen Turner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150107053316.GO4574@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).