Re: gdb support for Linux vsyscall DSO

[Roland McGrath <roland at redhat dot com>]

> To follow up my own e-mail.  On Solaris, there is:
> 
> 	/proc/PID/auxv
[...]
> So the /proc solution even as ``prior art''.

Indeed.  When I said, "like /proc/PID/auxv on Solaris", I was in fact
citing the existing Solaris interface as exactly what we might do.
However, as I said and for reasons I explained, we might not get buy-in
from kernel maintainers for supporting that.  I don't think that the prior
art of Solaris interfaces is something they find particularly compelling.

I'm not saying this feature won't happen--I certainly like it fine.  My
intent in starting the thread about the various possible sorts of kernel
interface was to flesh out the full range of acceptable options and their
preference ordering from the gdb perspective, to have on hand when I go and
argue for whichever of them we can get from the kernel maintainers.

> and the corresponding core file includes a .note section that contains 

I'm aware of the Solaris formats (which are all pretty reasonable).  If
Linux kernel maintainers accept the /proc/PID/auxv implementation, then I
am quite sure they will also accept NT_AUXV note writing (the kernel
support required is the same for both).  However, the core note does not
provide any new magic bullet.  There would still be new code required to
grok it; that code is straightforward, but both a bit more complex and a
bit more costly than the core phdr support that is already there now.

> As for the remote case, I think GDB's remote protocol (via the target 
> vector) should allow access to the remote file system (lib*.so, /proc, 
> ....) anyway.  Doing that would let the OS dependant code access the 
> remote /proc/PID/aux.  All sorts of useful things would suddenly ``just 
> work''.

I have nothing against that.  It obviously makes any /proc-based solution
work for remote (requiring /proc be mounted is an issue for both native and
remote).  I assume then that linux-proc.c would be made to use some new
target interface for the file-reading and thus start working via remote.
Then the support for reading either /proc/PID/auxv or /proc/PID/maps to
discern the vsyscall DSO address naturally fits there, machine-independent.

> To me this looks like the simplest and cleanest way of solving the 
> problem.  A conistent mechanism to find the address, and a single 
> technique for accessing the .eh_frame info.  That has to be better than 
> approaches that require per-target custom modifications for what is a 
> Linux specific problem.

As I said before, I am certainly happiest with someplace to put the
kernel-specific support that is not machine-specific.  The support for
using core file phdrs (to sort of treat the core file as if it were the
DSO) is so simple (and already works), that I am inclined to leave that
rather than reading the vsyscall DSO image out of the core file memory dump
after using the NT_AUXV note to locate it.  The code for making a bfd from
the in-memory DSO image is already needed for the live case, so that's not
extra work.  But as well as it being more efficient to use the core file
bfd directly rather than read part of the file into memory and make that
into a separate bfd, it's also simpler, slightly more efficient, and
already done(!), to use the core file's PT_GNU_EH_FRAME (and then you've
got it right there) than to even to look for an NT_AUXV note and the
AT_SYSINFO_EHDR element within it before you can fake up the bfd and search
it for eh_frame.


Thanks,
Roland