This is the mail archive of the gdb@sourceware.org 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]

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


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