i386-linux signal backtraces broken

[Daniel Jacobowitz <drow at mvista dot com>]

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