Re: gdb support for Linux vsyscall DSO

[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.

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.

> 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, for processes started by GDB we can read the auxiliary vector from
> the pristine stack, but that doesn't work for attached-to processes.

Good point.  I am inclined to think this is worth doing because, for the
case it covers, it is both fully robust and fully remote-friendly even with
old existing remote stubs, and is easy enough to implement on a per-target
basis.  If a direct inquiry is available, that will still be quicker than
the straightforward but numerous inferior memory reads that must be done to
extract the information from the stack, and so is the first choice; if it's
available for remote too, all the better.  But I think I will implement
this fallback at least for i386, just because it's a 100% correct solution
for at least half the cases (i.e. run but not attach) that can work today
without waiting for the a new kernel feature and/or remote stub upgrades to
be installed.

> Given that we know where the dynamic section is from l_ld, I think we
> can figure out all we need to know from there.

As a special case for the Linux vsyscall DSO, it would be adequate just to
presume it will fit in a single page and round down.  But you've reminded
me that there are other useful addresses to be found by looking in the
.dynamic section itself.  DT_HASH gives the location of the .hash section,
which a normal ld -shared always puts as the first section in the file,
appearing right after the file and program headers.  Without relying on
.hash being first per se, you can reasonably assume that the sections
referenced by DT_* are the first group in the file and so start with the
lowest of those addresses.  Rounding that address down to the smallest of
any actual ELF platform's page size (which might be 4k?) is a pretty darn
reasonable guess for finding the ELF header of any mapped DSO.


Thanks much for all the helpful feedback,
Roland