From: Andrew STUBBS <andrew.stubbs@st.com>
To: gdb@sources.redhat.com
Subject: RFC: GDB as a loader 1/3: silent batch mode
Date: Tue, 18 Oct 2005 11:28:00 -0000 [thread overview]
Message-ID: <4354DBFF.7000601@st.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]
Hi all,
It is my experience that GDB is often used, by means of the --batch and
--command options, as a mechanism for downloading and running programs
on remote targets (development boards and the like). This may be using a
sledgehammer to crack a nut, but given that a debugger is always
required in these cases and that creating an additional specific loader
requires effort, it is not surprising that it is used for this purpose.
I have therefore created a number of features to make this process a
little more comfortable. I have split them into separate posts so that
they may be discussed separately.
All have been regression tested for both i686-pc-linux-gnu and sh-elf an
have produced no new failures. I have not attempted to produce any new
test cases. Probably there should be some, but where and how?
Silent Batch Mode
The attached patch implements a new option --batch-silent. This does
much the same a --batch, except that it also disables gdb_stdout. This
means that all GDB outputs, other than errors, are hidden.
The advantage of this is that I no longer have to create dodgy scripts
to filter out all the various GDB messages from my program output
(Loading section ..., Process exited successfully, etc.).
Obviously this is not particularly useful with targets such as the GDB
simulator that give their output through the GDB print mechanisms.
However, all targets which print via regular stdout (as our custom
target interface here at ST does) work fine. Perhaps somebody could
suggest a solution for those targets with which it does not work.
This patch does not affect the behaviour of stderr or gdb_stderr - an
error is still an error.
Thanks
Andrew Stubbs
[-- Attachment #2: batch-silent.patch --]
[-- Type: text/plain, Size: 2483 bytes --]
2005-10-18 Andrew Stubbs <andrew.stubbs@st.com>
* event-top.c (gdb_setup_readline): Don't set gdb_stdout when
--batch-silent option was given.
* main.c (batch_silent): New variable.
(captured_main): Add new option --batch-silent.
(print_gdb_help): Likewise.
Index: src/gdb/event-top.c
===================================================================
--- src.orig/gdb/event-top.c 2005-03-16 17:05:31.000000000 +0000
+++ src/gdb/event-top.c 2005-10-17 17:38:27.000000000 +0100
@@ -1110,8 +1110,10 @@ gdb_setup_readline (void)
that the sync setup is ALL done in gdb_init, and we would only
mess it up here. The sync stuff should really go away over
time. */
+ extern batch_silent;
- gdb_stdout = stdio_fileopen (stdout);
+ if (!batch_silent)
+ gdb_stdout = stdio_fileopen (stdout);
gdb_stderr = stdio_fileopen (stderr);
gdb_stdlog = gdb_stderr; /* for moment */
gdb_stdtarg = gdb_stderr; /* for moment */
Index: src/gdb/main.c
===================================================================
--- src.orig/gdb/main.c 2005-10-17 15:29:40.000000000 +0100
+++ src/gdb/main.c 2005-10-17 17:44:35.000000000 +0100
@@ -73,6 +73,9 @@ struct ui_file *gdb_stdtargin;
struct ui_file *gdb_stdtarg;
struct ui_file *gdb_stdtargerr;
+/* Support for the --batch-silent option. */
+int batch_silent = 0;
+
/* Whether to enable writing into executable and core files */
extern int write_files;
@@ -254,6 +257,7 @@ captured_main (void *data)
{"silent", no_argument, &quiet, 1},
{"nx", no_argument, &inhibit_gdbinit, 1},
{"n", no_argument, &inhibit_gdbinit, 1},
+ {"batch-silent", no_argument, 0, 'B'},
{"batch", no_argument, &batch, 1},
{"epoch", no_argument, &epoch_interface, 1},
@@ -384,6 +388,10 @@ captured_main (void *data)
cmdsize * sizeof (*cmdarg));
}
break;
+ case 'B':
+ batch = batch_silent = 1;
+ gdb_stdout = ui_file_new();
+ break;
#ifdef GDBTK
case 'z':
{
@@ -834,6 +842,7 @@ Options:\n\n\
fputs_unfiltered (_("\
-b BAUDRATE Set serial port baud rate used for remote debugging.\n\
--batch Exit after processing options.\n\
+ --batch-silent As for --batch, but suppress all gdb stdout output.\n\
--cd=DIR Change current directory to DIR.\n\
--command=FILE Execute GDB commands from FILE.\n\
--core=COREFILE Analyze the core dump COREFILE.\n\
next reply other threads:[~2005-10-18 11:28 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-18 11:28 Andrew STUBBS [this message]
2005-10-19 19:58 ` Eli Zaretskii
2005-10-21 14:26 ` Andrew STUBBS
2005-10-21 14:54 ` Eli Zaretskii
2005-10-21 15:42 ` Andrew STUBBS
2005-10-21 16:42 ` Daniel Jacobowitz
2005-10-21 17:06 ` Andrew STUBBS
2005-10-21 22:04 ` Eli Zaretskii
2005-10-27 17:57 ` Andrew STUBBS
2005-10-27 19:14 ` Eli Zaretskii
2005-10-28 9:52 ` Andrew STUBBS
2005-10-28 12:49 ` Eli Zaretskii
2005-10-28 14:01 ` Andrew STUBBS
2005-10-28 17:23 ` Eli Zaretskii
2005-10-28 17:35 ` Andrew STUBBS
2005-10-29 9:52 ` Eli Zaretskii
2005-10-28 20:38 ` Daniel Jacobowitz
2005-10-29 10:32 ` Eli Zaretskii
2005-10-28 20:40 ` Daniel Jacobowitz
2005-10-28 20:47 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4354DBFF.7000601@st.com \
--to=andrew.stubbs@st.com \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox