From: Pedro Alves <palves@redhat.com>
To: Yao Qi <qiyaoltc@gmail.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 3/3] Fix gdb.base/completion.exp with --target_board=dwarf4-gdb-index
Date: Thu, 23 Feb 2017 17:12:00 -0000 [thread overview]
Message-ID: <1f393936-38be-f3ba-f8a9-6985830ce560@redhat.com> (raw)
In-Reply-To: <86a89cc2u6.fsf@gmail.com>
On 02/23/2017 04:02 PM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
>
> Hi Pedro,
> I don't know much about symbtab,
>
>> - /* Find the symtab for SRCFILE (this loads it if it was not yet read
>> - in). */
>> - s = lookup_symtab (srcfile);
>> - if (s == NULL)
>> + /* Go through symtabs for SRCFILE and check the externs and statics
>> + for symbols which match. */
>> + iterate_over_symtabs (srcfile, [&] (struct symtab *symtab)
>> {
>> - /* Maybe they typed the file with leading directories, while the
>> - symbol tables record only its basename. */
>> - const char *tail = lbasename (srcfile);
>> -
>> - if (tail > srcfile)
>> - s = lookup_symtab (tail);
>
> This is removed, do we have something equivalent in iterate_over_symtabs?
AFAICS, yes, though via other means.
iterate_over_some_symtabs matches both the symtab name, and if that
fails, tries the symtab's resolved fullname.
The path actually fixes a bug related to this, it seems.
Before the patch, any random absolute path would match, like:
(gdb) b /silly/path/asdfasdfsdafasdfasdfsadfasdfasdfasdfasdfasdf/test.c:<tab>
a foo int main()
But then actually setting the breakpoint would fail:
(gdb) b /silly/path/asdfasdfsdafasdfasdfsadfasdfasdfasdfasdfasdf/test.c:main
No source file named /silly/path/asdfasdfsdafasdfasdfsadfasdfasdfasdfasdfasdf/test.c.
Make breakpoint pending on future shared library load? (y or [n]) n
While after the patch, only full paths that gdb can resolve in
find_and_open_source, according to the source lookup rules, match for
completion. I.e., in my quick test, completing "/home/pedro/tmp/test.c:",
which is the source file's real path, matches for completion, but the
silly path above does not.
If I move the source file elsewhere and use the "dir" command to
point GDB at it, completion now finds it there:
(gdb) b /home/pedro/tmp2/test.c:<tab>
#nothing
(gdb) dir /home/pedro/tmp2/
Source directories searched: /home/pedro/tmp2:$cdir:$cwd
(gdb) b /home/pedro/tmp2/test.c:
a foo int main()
(gdb) b /home/pedro/tmp/dirs/ctor.cc:main
Note: breakpoint 1 also set at pc 0x4005ba.
So this patch makes completion consistent with the rest of
gdb, which seems like a desirable change.
I'll try to come up with a test case for this.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2017-02-23 17:12 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-22 14:50 [PATCH 0/3] Introduce gdb::function_view & fix completion bug Pedro Alves
2017-02-22 14:50 ` [PATCH 2/3] Use gdb::function_view in iterate_over_symtabs & co Pedro Alves
2017-02-22 22:40 ` Yao Qi
2017-02-22 14:50 ` [PATCH 1/3] Introduce gdb::function_view Pedro Alves
2017-02-22 15:15 ` Simon Marchi
2017-02-22 17:40 ` Pedro Alves
2017-02-22 17:49 ` [PATCH v1.1 " Pedro Alves
2017-02-22 22:12 ` Yao Qi
2017-02-23 14:49 ` Pedro Alves
2017-02-23 15:11 ` Yao Qi
2017-02-23 15:20 ` Pedro Alves
2017-02-23 15:34 ` Yao Qi
2017-02-22 22:23 ` Yao Qi
2017-02-23 14:50 ` [PATCH v1.2 " Pedro Alves
2017-02-23 14:58 ` Yao Qi
2017-02-23 14:59 ` Pedro Alves
2017-02-22 18:02 ` [PATCH " Simon Marchi
2017-02-22 14:50 ` [PATCH 3/3] Fix gdb.base/completion.exp with --target_board=dwarf4-gdb-index Pedro Alves
2017-02-23 16:02 ` Yao Qi
2017-02-23 17:12 ` Pedro Alves [this message]
2017-02-23 17:24 ` [PATCH v2 0/2] " Pedro Alves
2017-02-23 17:24 ` [PATCH v2 1/2] symtab.c: Small refactor Pedro Alves
2017-02-23 21:45 ` Yao Qi
2017-02-24 17:45 ` Pedro Alves
2017-02-23 17:24 ` [PATCH v2 2/2] Fix gdb.base/completion.exp with --target_board=dwarf4-gdb-index Pedro Alves
2017-02-24 15:34 ` Yao Qi
2017-02-24 17:15 ` Pedro Alves
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=1f393936-38be-f3ba-f8a9-6985830ce560@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=qiyaoltc@gmail.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