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: Shared libraries and the solib interface


Kevin Buettner wrote:

This approach can be used even if the dynamic linker doesn't provide a
convenient function (or even an inconvenient function) to set a
breakpoint on. In such a case, the stub is presumably informed via
other means of the fact that a shared library has just been loaded. The stub could stop and tell GDB that it's just hit a fake "shared
library loaded" breakpoint. Your solib backend (on the GDB side) and
the stub would have to agree on some suitable address to use for this
purpose. There is some risk associated with lying to GDB in such a
manner, but this risk is mitigated by the fact that users don't
usually stop at these internal breakpoints. [Setting
``stop-on-solib-events'' does allow the user to stop though. Once you get
the basic machinery going, you'll want to remember to test with this
setting to make sure it's not too badly broken. It can, at times, be
extremely useful to allow a user-level stop when a solib related
breakpoint has been hit.]



Do you know of an example of this? And a second question is how does a generic stub inform the GDB (workstation side) app which shared library got loaded and where or is this not necessary?


There are other approaches that could be used, but most of these would
involve adding code to other (generic) portions of gdb. Since it's
more difficult to get approval for changes to generic code, it's probably
best to stick with mechanisms which are already in use by other targets.



Yeah, that's where I crashed and burned last time.


HTH,

Kevin






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