Re: gdb support for Linux vsyscall DSO

[Andrew Cagney <ac131313 at redhat dot com>]

> 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