This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdb support for Linux vsyscall DSO



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






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]