Re: gdb support for Linux vsyscall DSO

[Andrew Cagney <ac131313@redhat.com>]

>> On Sat, May 10, 2003 at 01:24:39PM -0400, Andrew Cagney wrote:
> 
>> > Roland,
>> > 
>> > How exactly does this vsyscall memory region(1) come to be?  For 
>> > instance, how does GLIBC come to know where it is - GLIBC would need the 
>> > region's address to perform a syscall to find the regions address.  If 
>> > the underlying mechanism is explained (this is far from a tranditional 
>> > lib*.so), GDB developers will be in a better position to judge the best 
>> > way of handling this.
> 
>> 
>> It's created initially by the kernel, and its address is passed via the
>> auxilliary vector on the stack, and read by ld.so.  Roland explained
>> later in his essay about some ways to get at the aux vector.
> 
> 
> The memory is always there.  As I explained near the end of my long
> message, the kernel tells the program where to find it with the
> AT_SYSINFO_EHDR (and AT_SYSINFO, which is now redundant) elements in the
> aux vector on the stack at at startup.
> 
> The glibc dynamic linker code sets up its own data structures for the
> vsyscall DSO as if it had been mapped itself.  There is no special case in
> glibc that points at the eh_frame info.  Exception handling in libgcc
> already uses a dynamic linker callback to see the phdrs of all DSOs in core
> and follow their PT_GNU_EH_FRAME pointers.  The vsyscall DSO's eh_frame
> info is found by this mechanism like other DSOs' are.  
> 
> 
>> > Is there, for instance, anything to prevent GDB locating the symbol (in 
>> > GLIBC) that points at the vsyscall area and then using that?  Similar 
>> > for any mapped in eh_frame region.  Assuming that GDB has a well defined 
>> > trigger point for knowing when the symbol can be referenced - but GDB 
>> > would need that anyway.
> 
> 
> Nothing prevents it but class.  The vsyscall DSO is a Linux kernel feature,
> not a glibc feature.  It isn't proper layering for the support for it to
> depend on glibc internals.  There are any number of things that could be
> done simpler by presuming the form of glibc internals and requiring they be
> there.  That doesn't make them the right things to do.

It doesn't make it the wrong thing to do either.  As they say, keep it 
simple.  What was posted was a worryingly long list of changes for 
something that should be relatively straight forward - find the eh-frame 
stuff and use it.

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 :-/

Andrew