i386-linux signal backtraces broken

i386-linux signal backtraces broken

[Daniel Jacobowitz]

Right now, we have this:
static int
i386_linux_pc_in_sigtramp (CORE_ADDR pc, char *name)
{ 
  if (name)
    return STREQ ("__restore", name) || STREQ ("__restore_rt", name);

  return (i386_linux_sigtramp_start (pc) != 0
          || i386_linux_rt_sigtramp_start (pc) != 0);
}


There's only one problem here.  On my desktop (Debian GNU/Linux, glibc
2.2.5), there are two copies of sigaction in a dynamically linked
executable.  One of them's in libc.so.6 and the other is in ld-linux.so.2.
The only __restore symbol we find is in ld-linux.so.2; this seems to be
because we leave a symbol table in ld-linux.so.2 (probably for the
debugger's benefit, so that it can find _dl_debug_state) - but we strip
libc.so.6.

Unfortunately, the application gets the copy of __restore that is in
libc.so.6.  Which is right after a function whose name appears in the
dynamic symbol table (sigaction).  So it's considered to be part of
sigaction, and NAME is "sigaction".

If you statically link the application, everything works fine.

We have two choices, that I see:
  - Call the code inspection functions always
  - Call the code inspection functions if the name is sigaction, taking
    advantage of the glibc implementation detail that sigaction is the
    only exported name for this function that I can see, and they are
    implemented right after it in the same file.

Option (A) is a performance hit.  Option (B) is, well, a little fragile.

Thoughts?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: i386-linux signal backtraces broken

[Kevin Buettner]

On Oct 10,  2:47pm, Daniel Jacobowitz wrote:

> We have two choices, that I see:
>   - Call the code inspection functions always
>   - Call the code inspection functions if the name is sigaction, taking
>     advantage of the glibc implementation detail that sigaction is the
>     only exported name for this function that I can see, and they are
>     implemented right after it in the same file.
> 
> Option (A) is a performance hit.  Option (B) is, well, a little fragile.
> 
> Thoughts?

It sounds to me like option (A) is the way to go.  How bad is the
performance hit?

Kevin

Re: i386-linux signal backtraces broken

[Daniel Jacobowitz]

On Thu, Oct 10, 2002 at 12:06:06PM -0700, Kevin Buettner wrote:
> On Oct 10,  2:47pm, Daniel Jacobowitz wrote:
> 
> > We have two choices, that I see:
> >   - Call the code inspection functions always
> >   - Call the code inspection functions if the name is sigaction, taking
> >     advantage of the glibc implementation detail that sigaction is the
> >     only exported name for this function that I can see, and they are
> >     implemented right after it in the same file.
> > 
> > Option (A) is a performance hit.  Option (B) is, well, a little fragile.
> > 
> > Thoughts?
> 
> It sounds to me like option (A) is the way to go.  How bad is the
> performance hit?

Hard to say, since I don't have any way to test GDB's reaction speed...
it's going to mean at least one more read from target memory per frame
in a backtrace, for instance.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: i386-linux signal backtraces broken

[Mark Kettenis]

Daniel Jacobowitz <drow@mvista.com> writes:

> There's only one problem here.  On my desktop (Debian GNU/Linux, glibc
> 2.2.5), there are two copies of sigaction in a dynamically linked
> executable.  One of them's in libc.so.6 and the other is in ld-linux.so.2.
> The only __restore symbol we find is in ld-linux.so.2; this seems to be
> because we leave a symbol table in ld-linux.so.2 (probably for the
> debugger's benefit, so that it can find _dl_debug_state) - but we strip
> libc.so.6.

How unfortunate.  I'd recommend using an unstripped libc.so.6 when
doing any serious debugging, but I guess that won't trick the Debian
folks into distributing an unstripped libc.

> Unfortunately, the application gets the copy of __restore that is in
> libc.so.6.  Which is right after a function whose name appears in the
> dynamic symbol table (sigaction).  So it's considered to be part of
> sigaction, and NAME is "sigaction".
> 
> We have two choices, that I see:
>   - Call the code inspection functions always
>   - Call the code inspection functions if the name is sigaction, taking
>     advantage of the glibc implementation detail that sigaction is the
>     only exported name for this function that I can see, and they are
>     implemented right after it in the same file.

We could also modify glibc such that __restore and __restore_rt get
included in libc.so's dynamic symbol table.  Or perhaps we could
modify GDB such that it scans libc.so.6 for signal trampolines when it
is loaded.

> Option (A) is a performance hit.  Option (B) is, well, a little fragile.

I don't think implementing (B) makes the code more fragile than it
already is.

Mark

Re: i386-linux signal backtraces broken

[Daniel Jacobowitz]

On Sat, Oct 12, 2002 at 07:50:38PM +0200, Mark Kettenis wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > There's only one problem here.  On my desktop (Debian GNU/Linux, glibc
> > 2.2.5), there are two copies of sigaction in a dynamically linked
> > executable.  One of them's in libc.so.6 and the other is in ld-linux.so.2.
> > The only __restore symbol we find is in ld-linux.so.2; this seems to be
> > because we leave a symbol table in ld-linux.so.2 (probably for the
> > debugger's benefit, so that it can find _dl_debug_state) - but we strip
> > libc.so.6.
> 
> How unfortunate.  I'd recommend using an unstripped libc.so.6 when
> doing any serious debugging, but I guess that won't trick the Debian
> folks into distributing an unstripped libc.

Never happen, I think.

> > Unfortunately, the application gets the copy of __restore that is in
> > libc.so.6.  Which is right after a function whose name appears in the
> > dynamic symbol table (sigaction).  So it's considered to be part of
> > sigaction, and NAME is "sigaction".
> > 
> > We have two choices, that I see:
> >   - Call the code inspection functions always
> >   - Call the code inspection functions if the name is sigaction, taking
> >     advantage of the glibc implementation detail that sigaction is the
> >     only exported name for this function that I can see, and they are
> >     implemented right after it in the same file.
> 
> We could also modify glibc such that __restore and __restore_rt get
> included in libc.so's dynamic symbol table.  Or perhaps we could
> modify GDB such that it scans libc.so.6 for signal trampolines when it
> is loaded.

I don't like the former very much; then we'll require a newer libc for
this to work.  The latter would work...

> > Option (A) is a performance hit.  Option (B) is, well, a little fragile.
> 
> I don't think implementing (B) makes the code more fragile than it
> already is.

That's true.  I'll put together a patch for (B) in a few days, then. 
After I finish the host of changes needed for MIPS GNU/Linux signal
backtracing... it's proving quite complicated :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer