Re: unwind support for Linux 2.6 vsyscall DSO

[Roland McGrath <roland at redhat dot com>]

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

Ok, glad to hear it.  The mess there now was less than inspiring.  It's
pretty damn confusing figuring out when CLEAR_SOLIB gets called for one
thing (and when clear_solib does but not CLEAR_SOLIB!).

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

None of those hooks is in quite the right place, so we'll need a new one.

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

Is this in the context of a new TARGET_SO_* hook or without it?  The
fetch_link_map_offsets thing is some special magic internal to solib-svr4.c
and not matched with a target_so_ops hook.  Are you talking about
replicating that?  A new target_so_ops hook is needed to get called in the
right places.  That being the case, are you suggesting a
set_solib_svr4_new_hook_name that changes svr4_so_ops.new_hook_name?
Or what exactly?  We also need to do something at clear_solib time.
There is a target_so_ops hook for that already, but we need to call the old
svr4_clear_solib as well as do the new linux-specific work.

>  - See if TARGET_SO_SPECIAL_SYMBOL_HANDLING can be made to work.  (It's
>    already called by solib_add.)

It's only called if other symbols were loaded.  So at startup it won't be
called, and if `set auto-solib-add 0' has been done it won't ever be called.

>  - Add a new TARGET_SO_... method which is called from solib_add().

Unless solib_add is changed to call TARGET_SO_SPECIAL_SYMBOL_HANDLING
unconditionally, we need something new.  

>  - Add a new gdbarch method which is called from solib_add().

There are so many different function tables in gdb, I haven't the foggiest
idea how this meaningfully differs from target_so_ops additions.  I
certainly don't know any reasons to prefer the gdbarch flavor if you find
it less preferable.