This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Intrusive GDB Symbol Lookup when debugging remotely
Hello,
No-one responded to this, but I'm sure someone on this list understands
how difficult it would be to implement a new handler for a signal to run
gdb in a "Local" mode when connected to a gdbserver. I'd really
appreciate an estimate of how much effort this would be, or where in the
code to start looking.
Cheers
Dave
David Steven Trollope wrote:
Hello!
I'm trying to determine if there exists an alternative solution, or a
patch for the following problem, or if someone familiar with the GDB
source can estimate how much work it would be to implement a patch.
Any advice would be welcome and appreciated.
Configuration:
GDB running on a Sun Solaris machine.
GDBServer running on a PowerPC Linux machine
The application is running on the target in GDBServer and GDB is
connected to the target using "target remote x.x.x.x:y"
Problem:
While the target is running, I don't think it is possible to examine
the symbol table from within gdb without sending an interrupt signal
to GDB. This is a problem because users (and frontends) don't seem to
be able to look up symbols in the symbol table in GDB without
interrupting the target.
In theory, it would be possible to stop the interrupt being propogated
to the server and hence the target could remain running without
interruption. One possible way of solving this would be to use a
different signal as a "Non-intrusive interrupt" or "Local Interrupt".
The symbol lookup can occur, and then gdb resumes. This would imply
gdb would need to know if its running in "Local" or "Remote" mode to
prevent operations trying to access the target.
An alternative mechanism could be to have a separate thread that runs
and is signalled for non-intrusive operations.
You might ask why not just run a separate gdb instance to do this kind
of look up? However, I am dealing with large executables where loading
separate instances for the sake of a symbol lookup is neither
efficient, timely or practical.
I would very much appreciate discussion on this topic with regard to
feasibility, if its been done already or how much effort it would be
to implement this type of functionality.
Cheers
Dave Trollope