This is the mail archive of the gdb@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: 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
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


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