Re: unwind support for Linux 2.6 vsyscall DSO

[Jim Blandy <jimb at redhat dot com>]

Roland McGrath <roland@redhat.com> writes:
> > 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.
> 
> I certainly agree with this in principle.  But in practice I found that
> other shared libraries are handled with complicated hair that it's
> difficult to figure out exactly who calls and when, so I got scared.
> 
> > 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.
> 
> What can I see SOLIB_ADD gets called a lot, and every time it reconstructs
> the inferior's list of objects and compares to gdb's list to see if there
> are any new ones.  The vsyscall DSO is always there and is only possibly
> changed by an exec, so it doesn't make sense to re-check its location a lot.
> Should this SOLIB_ADD then just store whether it has checked yet and clear
> that record in SOLIB_CLEAR?

I think that's what it would take.  Open to better ideas, I'm just
doing the best I can. :)

> > 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.
> 
> The notion of auxv information is at least ELF-specific, and in fact a
> little more specific than that (a system need not use the canonical program
> startup stack protocol to use the ELF file formats).  The style of getting
> the auxv information is so far the same on every system I'm aware of that
> provides a method, i.e. Solaris and Linux (now) both have NT_AUXV in core
> files and /proc/PID/auxv for live processes.

When I say "target vector", I mean 'struct target_ops', not 'struct
gdbarch'.  That is, for core files you ask BFD for the .auxv section,
whereas for live processes you open /proc/PID/auxv.  The code dealing
with the vsyscall solib in the shared library handler (or whereever)
would just call target_get_auxilliary_vector, and the target stack
would decide where to look for it.

> > It seems to me this belongs in a new linux-tdep.c file.
> 
> Agreed.
> 
> > 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.
> 
> Though the AT_* values in use are a small set with few holes, it's actually
> an arbitrary tag and not an index of any kind.  Nothing general-purpose can
> assume the range of values is appropriate for an index, and no API
> should.

Okay, maybe that's not the greatest API.

> BFD is overkill for this (not that I'm saying BFD isn't overkill for
> everything).  There is no variation in the format among ELF flavors, it's
> just an even number of words in the format word size.  The very notion of
> an auxilliary vector is ELF-specific; if a non-ELF backend had something
> useful to export in the way of an auxilliary data from somewhere extraction
> interface, it seems doubtful it would be a useful abstraction to call the
> two the same thing in the frontend interface.  I don't have any objection
> to moving the parsing portion out somewhere else, but making it any more
> overblown than the few dozen lines of code it is would be pointless IMHO.

Yeah, I had in mind another elf-specific BFD function, like the one
that reads the solib data from memory.  All I'm suggesting is, take
the code that you've got, move it into bfd, and call it
bfd_elf_auxilliary_vector_sysinfo_ehdr.