This is the mail archive of the
mailing list for the GDB project.
Re: problem with fetch_link_map_offsets
- From: "Kris Warkentin" <kewarken at qnx dot com>
- To: "Andrew Cagney" <ac131313 at redhat dot com>
- Cc: "Gdb at Sources dot Redhat dot Com" <gdb at sources dot redhat dot com>, <kevinb at redhat dot com>
- Date: Tue, 29 Apr 2003 09:27:20 -0400
- Subject: Re: problem with fetch_link_map_offsets
- References: <020701c30dc3$bd8cf020$0202040a@catdog> <3EAD9BB8.firstname.lastname@example.org>
> > All of a sudden I'm getting a complaint about "No shared lib support for
> > this OS/ABI" from the new svr4_have_link_map_offsets function. When I
> > initialize my backend tdep file, I set the fetch_link_map_offsets
> > If I break on svr4_fetch_link_map_offsets, the first couple times I see
> > flmo is set to my function, then the third time it's been set back to
> > legacy_fetch_link_map_offsets. I set a break on
> > set_solib_svr4_fetch_link_map_offsets and see it being called with my
> > function but it never gets called again between when I set it and when
> > shows up as changed.
> > Can someone tell me where to set a watchpoint to catch the gdbarch data
> > being set? I'm still a little shakey on how that all works.
> An aside, "set debug arch 1", and watch to see if any other
> architectures are being initialized or selected.
Wow...talk about verbosity. At least now I've ruled out any other arches
being selected. I was pretty sure that they weren't because I had set a
break on set_solib_svr4_fetch_link_map_offsets and it was only called by us.
Since that's the only interface to change the lmo function, it would seem
like it has to be happening in the solib-svr4.c file somewhere. That's why
I was hoping to set a watchpoint.