This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
gdb "automation" question
- From: Steffen Dettmer <steffen dot dettmer at googlemail dot com>
- To: gdb at sourceware dot org
- Date: Tue, 22 Jun 2010 16:50:53 +0200
- Subject: gdb "automation" question
Hi,
I've got questions regarding gdb "automation" which I want to use
to pass "log file" information from a remote target.
I am using arm-elf-gdb-6.8.
How do I get "log" information from my application via remote gdb?
Here an overview what I'm doing currently and I would like to archive.
I have an embedded device and run remote gdb. I can load my
applicate with "remote put" (after "target remote"). Remote
device needs to be rebooted and gdb needs to reconnect (via
"target remote"). I use user "define"d commands to do so. The
user defined commands also disable all breakpoints, because
otherwise gdb does not connect (maybe a limitation of the used
remote monitor).
The logging library (e.g. on linux) can print via STDERR, so when
debugging native programs locally, I can see the log messages
easily. Of course this does not work with remote targets.
So I use a small log handler that concatenates the logmessages to
a global static char globalLogBuffer[big_enough]. This can be
shown via gdb. I can for example use:
define show_log
if globalLog[0] != 0
printf "%s", globalLog
endif
set globalLog[0] = 0
end
However, it would be better to automatically show the messages.
Best would be to show this right after a message was added. So in
the log handler I added a call to an empty static function
logHook() and tried:
define ena_log
b logHook
commands
silent
show_log
continue
end
end
This has the big disadvantage that it breaks stepping (commands
"next" and so on), because when in "next" the logHook break point
is reached (as usual for most high-level debugging), continue is
invoked and the position of the interactive debug is lost
(without the continue, it stops in the logHook, also not
helpful). Another problem is that to reconnect all breakpoints
must be disabled ("dis") but afterwards cannot be enabled ("ena"
would enable all breakpoints, including the breakpoints disabled
before the "dis" - of course!). The numbers of the break points
of course change, so the script cannot do something like "ena 12"
or "enable breakpoint m/logHook/" or so.
Without the single-stepping issue this would be lovely. It works
nicely (except the show-stopping "next" issue).
I though simplest workaround would be
define hook-stop
show_log
end
Unfortunately directly after rebooting (before "target remote"
and "continue"), the hook cannot work. I have to CTRL-C all the
time to cancel hook execution. So I tried to add this to my user
defined commands. They call a command "defaction" which I
extended:
define defaction
.... other default actions ...
define hook-stop
show_log
end
end
but I get an error ("This command cannot be used at top level").
any ideas how I could get around those issues?
Best would be a kind of "at this position perform an action and
continue" that would not interference with user breakpoints and
stepping with "next".
Also if someone knows some workaround or has an completely
different approach I would appreciate to read about :-)
oki,
Steffen