From: Joel Brobecker <brobecker@adacore.com>
To: S?bastien Granjoux <seb.sfo@free.fr>
Cc: gdb-patches@sourceware.org
Subject: Re: Fix breakpoints when several source files have the same name
Date: Tue, 29 Sep 2009 22:20:00 -0000 [thread overview]
Message-ID: <20090929222024.GH6362@adacore.com> (raw)
In-Reply-To: <4A1926A2.1000806@free.fr>
Sebastien,
Really really sorry for taking so long before reviewing this patch.
Please don't hesitate to send pings on the list to remind us of a patch
that is sitting unreviewed for more than a week or two.
> There is in gdb 6.8 a new bug that makes breakpoints inserted at the
> wrong place when a program has several files with the same base name (in
> different directories).
[...]
> I have found it using the mi interface but it appears in the same way
> with the other commands.
For the record, here is how I reproduced the issue on my side:
I have two small files a/foo.c and b/foo.c, each containing an empty
function called foo_a and foo_b (resp). Then a file main.c:
extern void foo_a (void);
extern void foo_b (void);
int
main (void)
{
foo_a ();
foo_b ();
return 0;
}
To build, I did:
% (cd a && gcc -c -g foo.c)
% (cd b && gcc -c -g foo.c)
% gcc -o main main.c a/foo.o b/foo.o
The important part here, is to compile both foo.c files from
within the directory where these files are located, at least
with GCC.
Trying to break on either location, using the filename's fullname,
results in 2 breakpoints being inserted instead of just one:
(gdb) b /t.a/brobecke/ex/break/a/foo.c:3
Breakpoint 1 at 0x400480: file foo.c, line 4. (2 locations)
(gdb) b /t.a/brobecke/ex/break/b/foo.c:3
Note: breakpoint 1 also set at pc 0x400480.
Note: breakpoint 1 also set at pc 0x400478.
Breakpoint 2 at 0x400480: file foo.c, line 4. (2 locations)
> 2009-05-24 Sebastien Granjoux <seb.sfo@free.fr>
>
> PR mi/9583:
> * symtab.c (find_line_symtab): Use full filename if available
My concern with your approach is with performance: symtab_to_fullname
and psymtab_to_fullname are actually a bit expensive to call, as they
involve locating the file on the local host disk, taking into account
debugging info as well as the source path (see the "dir" command) and
then opening/closing that file if found.
How about changing the patch to only do the fullname matching iff
(if and only iff) the simple filename matches first. In other words,
compute the symtab/psymtab fullname only if the filename matches.
--
Joel
next prev parent reply other threads:[~2009-09-29 22:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-24 10:49 Sébastien Granjoux
2009-09-29 22:20 ` Joel Brobecker [this message]
2009-09-30 18:53 ` Sébastien Granjoux
2009-09-30 19:07 ` Jan Kratochvil
2009-10-01 21:05 Sébastien Granjoux
2009-10-01 21:45 ` Joel Brobecker
2009-10-02 20:28 ` Sébastien Granjoux
2009-10-29 21:55 Sébastien Granjoux
2009-11-09 20:31 Sébastien Granjoux
2009-11-09 21:09 ` Joel Brobecker
2009-11-09 21:38 ` Sébastien Granjoux
2009-11-09 22:05 ` Joel Brobecker
2009-11-10 18:46 ` Sébastien Granjoux
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=20090929222024.GH6362@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=seb.sfo@free.fr \
/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