Re: unwind support for Linux 2.6 vsyscall DSO

[Daniel Jacobowitz <drow at mvista dot com>]

On Thu, Oct 09, 2003 at 12:58:05PM -0700, Kevin Buettner wrote:
> 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().

The problem with using SOLIB_ADD for this is that we can't SOLIB_ADD
safely till we hit the dynamic linker breakpoint, but it would be
_really_ nice to be able to load this object right after the inferior
starts (and for static binaries, etc etc).  How would you suggets we do
that?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer