This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: i386 Linux signal trampoline support for gdb 4.18


   From: Andi Kleen <ak@muc.de>
   Date: 15 Jul 1999 22:02:09 +0200

   In article <19990714045151.11323.qmail@daffy.airs.com>,
   Ian Lance Taylor <ian@zembu.com> writes:

   > On most systems signal trampoline code is simply a libc function, so
   > it is comparatively easy to detect one.  The Linux kernel, however,
   > builds the signal trampoline on the stack.  This patch works by
   > looking for the particular set of instructions the Linux kernel places
   > on the stack.  This test should rarely give a false positive, because
   > the kernel builds instructions which invoke the sigreturn system call,
   > which is only useful when returning from a signal handler.  It is of
   > course possible that the kernel behaviour will change at some later
   > date, in which case this test will have to be modified.

   On the post 2.1 tree glibc has switched to a libc function and set 
   SA_RESTORER (actually it did have the function since ages, but forgot
   to set the flag so the kernel never used it). The functions are called
   __restore and __restore_rt, I am not sure if they're exported though.
   The code is basically similar except that __restore_rt calls 
   rt_sigreturn instead of sigreturn for queued realtime signals in 2.2.
   The kernel trampoline has a rt_sigreturn version too (syscall 173 instead of 
   of 119), this should probably be handled. 

That sounds as though it can be tested for using a traditional
IN_SIGTRAMP test, such as the default in inferior.h:

#define IN_SIGTRAMP(pc, name) \
       (name && STREQ ("_sigtramp", name))

Just test for __restore or __restore_rt.

   So post glibc 2.1 can be only handled by either adding lots of ptrace traffic
   (checking  for the signature for every backtrace address), or by teaching
   gdb about glibc internals.

It's normal to use libc internals for signal trampoline detection.

   The code needs to be changed to handle syscall 173 too, otherwie it'll
   lose with RT signals.

I unfortunately don't use glibc 2.1, so I can't test either of these
options.

As far as I can tell, my patch is still appropriate, so that gdb will
work correctly on systems using older glibc versions.  It will need to
be enhanced for later glibc versions, but it will also work correctly
as is; it will simply fail to recognize signal trampolines when using
glibc 2.1, which is exactly what happens without my patch.

Ian

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]