Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath <roland@redhat.com>]

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

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

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