This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: unwind support for Linux 2.6 vsyscall DSO


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]