Re: unwind support for Linux 2.6 vsyscall DSO

[Jim Blandy <jimb at redhat dot com>]

Roland McGrath <roland@redhat.com> writes:
> Questions for the core file case:
> 
> 1 Where should this call go in the order of operations?  
> 
>   I plopped the check in the middle of core_open because it seemed like it
>   ought to come between the bfd opening and the register diddling that
>   includes some calls about the grokking of the stack frame.  I don't know
>   how loading a symfile interacts with that diddling.  Would it work to
>   have the symbol_file_add_from_memory done after core_open?

It seems to me that it should be handled as much like other shared
libraries as possible.  So at the point where we load symbols for the
shared libraries that a core file references, we also want to load the
vsyscall library, if it exists.  Same for attach and run.

One approach might be for Linux to define its own linux-solib.h, which
#defines SOLIB_ADD and SOLIB_CLEAR to call linux-tdep.c functions that
do the standard dynamic linker stuff, but then check the auxv for an
AT_SYSINFO_EHDR entry and handle that, too.  That would make things
work pretty consistently for the core, attach, and run cases.

It seems to me that there should be a target vector method for
accessing the auxv information, since there's one native-specific way
to do it for attach and run, and a core-specific way to do it for core
files.  But it's Linux-specific information.  Well, actually, any OS
that uses the SYSV-style program invocation process is going to work
that way, so maybe it's justifiable.  I don't know.


> 2 Where should this support go in the target/generic code split?
> 
>   This code, and the need for it, is Linux-specific but not machine-specific.
>   Linux 2.6 currently requires it on x86, IA64, and AMD64 (in both native and
>   IA32 emulation versions).  The user-level support for the preloaded DSO
>   image is machine-independent in the glibc implementation; no other Linux
>   platform will overload the AT_SYSINFO_EHDR tag value for another purpose.
>   I would like to have this implemented in gdb in a place that doesn't
>   require duplication for the three existing platforms requiring the support,
>   and will cover any other Linux target where kernels start using the same
>   feature.  I don't see any obvious place like a common linux-tdep.c; where
>   is the right place?  Should it be a different to_core_open hook that wraps
>   the generic one?  Or maybe extend struct core_fns?  (But core_fns is
>   redefined only in machine-specific files, and it appears inconsistently
>   so--sometimes in *-nat.c and sometimes in *-tdep.c; what's the story?)

It seems to me this belongs in a new linux-tdep.c file.


Regarding the code:

Would it be appropriate to move auxv_parse into BFD?  If I remember
right, the dynamic linker parses the auxilliary vector into an array
indexed by AT_* values; GDB could call something like that, and then
just pick out the AT_SYSINFO_EHDR value pretty easily.