This is the mail archive of the
gdb@sources.redhat.com
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.8050205@redhat.com>
> > 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
function.
> > If I break on svr4_fetch_link_map_offsets, the first couple times I see
that
> > 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
it
> > 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.
cheers,
Kris