Re: gdb support for Linux vsyscall DSO

Andrew Cagney
2003-05-12T19:23:34Z

> Any way, re-reading your post yes, the info is in there. If the address is known, GDB can pull the contents out of memory. Given the list of targets:
>
> - core
> - native attach
> - native run
> - remote
> - ?more?
>
> I believe the choices are:
>
> - find a way of determing that address across all of these targets :-/
> - implement per-target custom mechanisms for pulling out this information (creating a need to test/implement each target separatly - vis the corefile + dwarf2 changes) :-//
>
> So, it possible to find the address (symbol?, /proc, shlib load table, ...?) for all targets?
>
> /proc/PID/map, on a remote, is a possability. A remote version of find_memory_regions() would be useful anyway - clean up gcore a bit. However, the down side is that a system with no /proc mounted wouldn't debug very well :-/

To follow up my own e-mail. On Solaris, there is:

/proc/PID/auxv

and the corresponding core file includes a .note section that contains
(man core.4):

auxv_t array
n_type: NT_AUXV. This entry contains the array of
auxv_t structures that was passed by the operating
system as startup information to the dynamic linker.
Auxiliary vector information is defined in
<sys/auxv.h>.

So the /proc solution even as ``prior art''.

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

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.

Andrew