This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: shared library support hookin the remote.c
Andrew Cagney wrote:
So each time the inferior stops, GDB will need to re-poll for shlib changes?
That is the way I currently have it set up.
There is one thing I don't understand about the F packet. How does the inferior know that it is OK to send the packet. From everything that I have read. Comunication is initiated by GDB and answered by the inferior. I didn't know that the stub could initiate a packet. If so, Do I just tack on the F packet information to the end of a currently generated packet?
It's new code (added last year). Instead of a normal stop, the inferior
reports an F, once that is handled the inferior is resumed again.
Corinna documented the interaction pretty well - see the relevant appendix.
This is the reason I was polling. Otherwise I prefer to not poll.
Can the stub instead generate a packet, very like the recently added F (File I/O) indicating that the link map changed (and what)?
I think I have answered this by answering the preceding question.
The other is to have a custom xxx-shlib hooked up to inferior stopped that queries for the stuff you describe. It could probably be tunneled as a TARGET_OBJECT_KOD packet.
If I implement the F packet would that get rid if the need for a xxx-shlib?
I think so.
Andrew