This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
how to fix internal errors on connection to remote stub?
- From: Sandra Loosemore <sandra at codesourcery dot com>
- To: <gdb at sourceware dot org>
- Cc: Luis Machado <lgustavo at codesourcery dot com>
- Date: Fri, 23 Jan 2015 10:47:39 -0700
- Subject: how to fix internal errors on connection to remote stub?
- Authentication-results: sourceware.org; auth=none
We have a GDB stub we use to interface to various hardware probes. In
GDB we normally run programs on the target using a series of commands like
(gdb) target remote ....
(gdb) load
(gdb) c
This works about 99.9% of the time. The other .1%, we get "a problem
internal to GDB has been detected" from the "target remote" command,
because it is trying to ask the target for a backtrace *before* it has
loaded the program. At that point, the contents of memory and registers
on the target have no relation to the program gdb is trying to debug,
and GDB gets mighty confused. Maybe this isn't so awful for manual use,
but it certainly screws up automated testing.
Luis and I have been discussing this and we both think the most likely
solution is for the stub to answer the initial '?' packet with some
response that indicates it's in an inconsistent state, rather than the
"S00" it is sending now, and have GDB recognize it and at least suppress
the initial backtrace, and perhaps also sets a flag disallowing other
commands to view target state (variable values, etc) until it's cleared
by the "load" command. Maybe the 'W' stop reply could be used for this
purpose, or maybe we need to introduce a new one?
Alternatively, maybe we could have a separate GDB command that can be
issued before the "target remote" to suppress the auto-backtrace?
Any other ideas? What do other folks think is the right solution? We'd
much rather fix this in a way that's acceptable for mainline rather than
having to carry a patch locally.
-Sandra