This is the mail archive of the gdb@sources.redhat.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]
Other format: [Raw text]

Re: gdb support for Linux vsyscall DSO


   Date: Mon, 12 May 2003 18:53:16 -0700
   From: Roland McGrath <roland@redhat.com>

   > There is some special handling for signal trampolines in
   > infrun.c:handle_inferior_event().  Beware!  Dragons can still be found
   > in that function.  However, it seems the bit of code I'm talking about
   > is there for targets that don't known how to properly unwind signal
   > frames :-).

   I only partly follow the code in that function, but it does look
   like it wants to know whether it's in a signal frame.  I get the
   impression that "next" or "step" interrupted by a signal lets the
   signal be handled and continues until the end of the source line
   rather than doing a normal user stop for the signal, and that this
   is considered desireable.  So it must know.

I'm not really sure.  The code I referred to seems to be written for
BSD-style signal trampolines, where the signal trampoline will call
the signal handler.  The Linux kernel calls the signal trampoline
directly, so perhaps it doesn't need this code.

   Having a DWARF2 extension to mark signal frames seems reasonable, and less
   kludgey than matching symbol names.  However, I wonder if there is in fact
   a way to do it that won't confuse older libgcc's .eh_frame unwinding code.

If the `z' augmentation doesn't confuse older libgcc's, I don't see
why adding another augmentation would do so.  But we should first
determine if we really need it before adding it.

   > Restoring %eflags is certainly possible.  Making GDB actually pop the
   > signal trampoline frame should work

   I only mentioned %eflags to pedantic because I caught myself about to say
   "restore the exact state of the interrupted thread" and that wasn't
   completely true.  I don't anticipate gdb having any reason to want to roll
   back a signal frame.  (However, in the abstract it seems like the right
   thing for the kernel unwind info to describe restoring %eflags if the
   DWARF2 format can already represent that.)

Well, GDB will do exactly that when the user gives the "return"
command in a signal trampoline.

Mark


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