Re: unwind support for Linux 2.6 vsyscall DSO

[Kevin Buettner <kevinb@redhat.com>]

On Oct 6,  9:45pm, Roland McGrath wrote:

> Ok, good.  Are people then agreed that adding a Linux-specific SOLIB_ADD
> that does this stuff in addition to calling solib_add is the way to go?

I do not want to see a linux-specific SOLIB_ADD added to gdb.  I'm
(still) trying to collapse all of the various SOLIB_ADD's down to just
one function.  Progress has been slow, but it's being made.

Adding a call to a new gdbarch method in solib_add() (in solib.c)
might be acceptable.  This method could be set up in the
{$arch}-linux-tdep.c files.

However, before going this route (adding a new gdbarch method), I'd
prefer that you look at TARGET_SO_SPECIAL_SYMBOL_HANDLING() to see if
it could be used to serve your purposes.  If it can't, then you should
consider adding a new TARGET_SO_... method which is called from
solib_add().  In either case, the hook for setting up a call to some
linux-specific code from solib-svr4.c could be done in a manner
similar that used to set the link map offsets fetcher.  See
set_solib_svr4_fetch_link_map_offsets() in solib-svr4.[hc].

To recap, here are my preferences (from most to least preferable):

 - See if TARGET_SO_SPECIAL_SYMBOL_HANDLING can be made to work.  (It's
   already called by solib_add.)
 - Add a new TARGET_SO_... method which is called from solib_add().
 - Add a new gdbarch method which is called from solib_add().

Kevin