From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7342 invoked by alias); 22 Jun 2010 14:51:04 -0000 Received: (qmail 7329 invoked by uid 22791); 22 Jun 2010 14:51:02 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from mail-ew0-f41.google.com (HELO mail-ew0-f41.google.com) (209.85.215.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 Jun 2010 14:50:57 +0000 Received: by ewy21 with SMTP id 21so275209ewy.0 for ; Tue, 22 Jun 2010 07:50:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.7.135 with SMTP id d7mr1363855ebd.11.1277218253166; Tue, 22 Jun 2010 07:50:53 -0700 (PDT) Received: by 10.213.35.145 with HTTP; Tue, 22 Jun 2010 07:50:53 -0700 (PDT) Date: Tue, 22 Jun 2010 14:51:00 -0000 Message-ID: Subject: gdb "automation" question From: Steffen Dettmer To: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-06/txt/msg00095.txt.bz2 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