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>, Kevin Buettner <kevinb at redhat dot com>
- Cc: Jim Blandy <jimb at redhat dot com>, Elena Zannoni <ezannoni at redhat dot com>, gdb-patches at sources dot redhat dot com
- Date: Thu, 9 Oct 2003 15:32:14 -0700
- Subject: Re: unwind support for Linux 2.6 vsyscall DSO
- References: <200310092207.h99M7jr4010466@magilla.sf.frob.com>
On Oct 9, 3:07pm, Roland McGrath wrote:
> > 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.
I was suggesting a hook or hooks, (using a mechanisms similar to
set_solib_svr4_fetch_link_map_offsets() for setting up the hook)
to be used either with existing or new TARGET_SO_* methods.
It sounds like this won't be sufficient for your purposes though.
I see you've sent some other mail on this matter. I'll reply further
there.
Kevin