From: Luis Machado <lgustavo@codesourcery.com>
To: <gdb-patches@sourceware.org>
Subject: [PATCH v2 1/2] Debugging without a binary (regression)
Date: Tue, 12 Apr 2016 19:24:00 -0000 [thread overview]
Message-ID: <1460489060-17307-2-git-send-email-lgustavo@codesourcery.com> (raw)
In-Reply-To: <1460489060-17307-1-git-send-email-lgustavo@codesourcery.com>
When we attempt to debug a process using GDBserver in standard remote mode
without a symbol file on GDB's end, we may run into an issue where GDB cuts
the connection attempt short due to an error. The error is caused by not
being able to open a symbol file, like so:
--
(gdb) set sysroot
(gdb) tar rem :2345
Remote debugging using :2345
/proc/23769/exe: Permission denied.
(gdb) i r
The program has no registers now.
(gdb)
It should've been like this:
(gdb) set sysroot
(gdb) tar rem :2345
Remote debugging using :2345
0xf7ddb2d0 in ?? ()
(gdb) i r
eax 0x0 0
ecx 0x0 0
edx 0x0 0
ebx 0x0 0
esp 0xffffdfa0 0xffffdfa0
ebp 0x0 0x0
esi 0x0 0
edi 0x0 0
eip 0xf7ddb2d0 0xf7ddb2d0
eflags 0x200 [ IF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb)
This is caused by a couple of function calls within exec_file_locate_attach
that can potentially throw errors.
The following patch guards both exec_file_attach and symbol_file_add_main to
prevent the errors from disrupting the connection process.
There was also a case where native GDB tripped on this problem, but it was
mostly fixed by bf74e428bca61022bd5cdf6bf28789a184748b4d.
Regression-tested on x86-64/Ubuntu.
Changes in v2:
- We are using two TRY/CATCH blocks to guard both exec_file_attach and
symbol_file_add_main.
- Adjusted code to display only a single warning message if both TRY/CATCH
blocks throw with the same error message.
- I had to duplicate the exception message string because the second CATCH
block will overwrite the contents of the pointer we saved.
gdb/ChangeLog:
2016-04-12 Luis Machado <lgustavo@codesourcery.com>
* exec.c (exec_file_locate_attach): Guard a couple functions
that can throw errors.
(exception_print_same): New helper function.
---
gdb/exec.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 59 insertions(+), 2 deletions(-)
diff --git a/gdb/exec.c b/gdb/exec.c
index a10ab9b..051a585 100644
--- a/gdb/exec.c
+++ b/gdb/exec.c
@@ -135,6 +135,25 @@ exec_file_clear (int from_tty)
printf_unfiltered (_("No executable file now.\n"));
}
+/* Returns non-zero if exceptions E1 and E2 are equal. Returns zero
+ otherwise. */
+
+static int
+exception_print_same (struct gdb_exception e1, struct gdb_exception e2)
+{
+ const char *msg1 = e1.message;
+ const char *msg2 = e2.message;
+
+ if (msg1 == NULL)
+ msg1 = "";
+ if (msg2 == NULL)
+ msg2 = "";
+
+ return (e1.reason == e2.reason
+ && e1.error == e2.error
+ && strcmp (e1.message, e2.message) == 0);
+}
+
/* See gdbcore.h. */
void
@@ -142,6 +161,7 @@ exec_file_locate_attach (int pid, int from_tty)
{
char *exec_file, *full_exec_path = NULL;
struct cleanup *old_chain;
+ struct gdb_exception prev_err;
/* Do nothing if we already have an executable filename. */
exec_file = (char *) get_exec_file (0);
@@ -182,9 +202,46 @@ exec_file_locate_attach (int pid, int from_tty)
old_chain = make_cleanup (xfree, full_exec_path);
- exec_file_attach (full_exec_path, from_tty);
- symbol_file_add_main (full_exec_path, from_tty);
+ /* exec_file_attach and symbol_file_add_main may throw an error if the file
+ cannot be opened either locally or remotely.
+
+ This happens for example, when the file is first found in the local
+ sysroot (above), and then disappears (a TOCTOU race), or when it doesn't
+ exist in the target filesystem, or when the file does exist, but
+ is not readable.
+
+ Even without a symbol file, the remote-based debugging session should
+ continue normally instead of ending abruptly. Hence we catch thrown
+ errors/exceptions in the following code. */
+ TRY
+ {
+ exec_file_attach (full_exec_path, from_tty);
+ }
+ CATCH (err, RETURN_MASK_ERROR)
+ {
+ if (err.message != NULL)
+ warning ("%s", err.message);
+
+ prev_err = err;
+
+ /* Save message so it doesn't get trashed by the catch problem
+ below. */
+ prev_err.message = xstrdup (err.message);
+ }
+ END_CATCH
+
+ TRY
+ {
+ symbol_file_add_main (full_exec_path, from_tty);
+ }
+ CATCH (err, RETURN_MASK_ERROR)
+ {
+ if (!exception_print_same (prev_err, err))
+ warning ("%s", err.message);
+ }
+ END_CATCH
+ xfree ((void *) prev_err.message);
do_cleanups (old_chain);
}
--
1.9.1
next prev parent reply other threads:[~2016-04-12 19:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-12 19:24 [PATCH v2 0/2] Debugging without a symbol file Luis Machado
2016-04-12 19:24 ` Luis Machado [this message]
2016-04-13 15:00 ` [PATCH v2 1/2] Debugging without a binary (regression) Pedro Alves
2016-04-13 15:16 ` Luis Machado
2016-04-12 19:24 ` [PATCH v2 2/2] Test GDB connection to GDBserver with no symbol files Luis Machado
2016-04-13 15:16 ` Pedro Alves
2016-04-13 15:24 ` Luis Machado
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=1460489060-17307-2-git-send-email-lgustavo@codesourcery.com \
--to=lgustavo@codesourcery.com \
--cc=gdb-patches@sourceware.org \
/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