This is the mail archive of the 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: problem with fetch_link_map_offsets

> > 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. 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.



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