From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Cc: Joel Brobecker <brobecker@adacore.com>
Subject: [PATCH] Fix regression in -file-list-exec-source-files command.
Date: Thu, 19 Aug 2010 09:18:00 -0000 [thread overview]
Message-ID: <1282209516-3612-1-git-send-email-brobecker@adacore.com> (raw)
This is to fix one of the issues that was blocking for the 7.2 release :).
See http://sourceware.org/ml/gdb/2010-07/msg00118.html for
a description of the problem. Namely, the file and fullname
fields are inverted in the output of the -file-list-exec-source-files
GDB/MI command:
(gdb) interpreter-exec mi -file-list-exec-source-files
^done,files=[{file="/takamaka.a/brobecke/ex/list-exec-source-files/foo.c",fullname="foo.c"},{file="/takamaka.a/brobecke/ex/list-exec-source-files/foo.c",fullname="foo.c"},{file="",fullname="init.c"},{file="",fullname="../sysdeps/x86_64/elf/start.S"},{file="",fullname="../sysdeps/x86_64/elf/start.S"}]
It turns out to be a silly thinko: The map_symbol_filenames function
calls the psymtab version of map_symbol_filenames routine, and this
version called the callback function with filename and fullname
in the wrong order (fullname/filename instead of filename/fullname).
The routine description in symfile.h confirst that expected order for
the FUN callback parameters:
/* Call a callback for every file defined in OBJFILE. FUN is the
callback. It is passed the file's name, the file's full name,
and the DATA passed to this function. */
void (*map_symbol_filenames) (struct objfile *objfile,
void (*fun) (const char *, const char *,
void *),
void *data);
Fixing this error uncovered another location where the arguments
were reversed: maybe_add_partial_symtab_filename. Once the first
error was fixed, the debugger would crash while attempting to do
completion, because it was given a NULL fullname instead of the
non-NULL filename.
IMO, we would had a better chance of avoiding this sort of issue if we
had named the parameters in the callback function. It was less than
immediate to verify the order of arguments when I found the source of
the first problem (unnamed parameters, and lack of function documentation).
What I suggest is to create a type for the function pointer callback,
and have the parameters named and documented... But that can be taken
care of through another patch.
gdb/ChangeLog:
* psymtab.c (map_symbol_filenames_psymtab): Call FUN with
the arguments in the correct order.
* symtab.c (maybe_add_partial_symtab_filename): Declare
the arguments in the correct order.
I've checked this in HEAD and 7.2 branch, as it seems sufficiently obvious.
This was tested on x86_64-linux in HEAD. I'll see whether it's possible
to create a regression test or not, next.
---
gdb/ChangeLog | 7 +++++++
gdb/psymtab.c | 2 +-
gdb/symtab.c | 2 +-
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index b889876..580be2b 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,10 @@
+2010-08-19 Joel Brobecker <brobecker@adacore.com>
+
+ * psymtab.c (map_symbol_filenames_psymtab): Call FUN with
+ the arguments in the correct order.
+ * symtab.c (maybe_add_partial_symtab_filename): Declare
+ the arguments in the correct order.
+
2010-08-19 Jan Kratochvil <jan.kratochvil@redhat.com>
* varobj.c (varobj_create): Replace variable old_fi with old_id,
diff --git a/gdb/psymtab.c b/gdb/psymtab.c
index bc47681..228b7a8 100644
--- a/gdb/psymtab.c
+++ b/gdb/psymtab.c
@@ -913,7 +913,7 @@ map_symbol_filenames_psymtab (struct objfile *objfile,
continue;
fullname = psymtab_to_fullname (ps);
- (*fun) (fullname, ps->filename, data);
+ (*fun) (ps->filename, fullname, data);
}
}
diff --git a/gdb/symtab.c b/gdb/symtab.c
index d43d573..baf6d94 100644
--- a/gdb/symtab.c
+++ b/gdb/symtab.c
@@ -4072,7 +4072,7 @@ struct add_partial_filename_data
/* A callback for map_partial_symbol_filenames. */
static void
-maybe_add_partial_symtab_filename (const char *fullname, const char *filename,
+maybe_add_partial_symtab_filename (const char *filename, const char *fullname,
void *user_data)
{
struct add_partial_filename_data *data = user_data;
--
1.7.1
next reply other threads:[~2010-08-19 9:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-19 9:18 Joel Brobecker [this message]
2010-08-19 10:01 ` Joel Brobecker
2010-08-19 16:35 ` Doug Evans
2010-08-19 18:35 ` [RFA/commit/testsuite] Add test for -file-list-exec-source-files Joel Brobecker
2010-08-19 18:55 ` Jan Kratochvil
2010-09-02 15:37 ` Joel Brobecker
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=1282209516-3612-1-git-send-email-brobecker@adacore.com \
--to=brobecker@adacore.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).