This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: unwind support for Linux 2.6 vsyscall DSO
- From: Kevin Buettner <kevinb at redhat dot com>
- To: Roland McGrath <roland at redhat dot com>, Jim Blandy <jimb at redhat dot com>
- Cc: Elena Zannoni <ezannoni at redhat dot com>, gdb-patches at sources dot redhat dot com
- Date: Thu, 9 Oct 2003 12:58:05 -0700
- Subject: Re: unwind support for Linux 2.6 vsyscall DSO
- References: <200310070445.h974jrd1020409@magilla.sf.frob.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