Re: gdb support for Linux vsyscall DSO

Andrew Cagney
2003-05-10T21:49:21Z

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