public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug symtab/15035] New: Excessive symtab expansion setting a breakpoint on foo::bar.
@ 2013-01-18 19:43 dje at google dot com
2025-02-22 3:20 ` [Bug symtab/15035] " tromey at sourceware dot org
2025-02-22 18:53 ` tromey at sourceware dot org
0 siblings, 2 replies; 3+ messages in thread
From: dje at google dot com @ 2013-01-18 19:43 UTC (permalink / raw)
To: gdb-prs
http://sourceware.org/bugzilla/show_bug.cgi?id=15035
Bug #: 15035
Summary: Excessive symtab expansion setting a breakpoint on
foo::bar.
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: symtab
AssignedTo: unassigned@sourceware.org
ReportedBy: dje@google.com
Classification: Unclassified
I haven't looked into the psymtab side, but when using .gdb_index and doing
(gdb) b (anonymous namespace)::foo
gdb will first expand every CU/TU (dwarf) that defines anonymous namespace, and
only after that will it look for foo.
However, the symbol table in .gdb_index has an entry for (anonymous
namespace)::foo. The data is there to tell gdb precisely which CUs to expand.
Seems like the index isn't being fully utilitized here.
In a large app there could be 2k such CUs (or more), and setting a breakpoint
takes way too long (long enough that I give up after a minute and haven't put
in the effort to compute the actual number).
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug symtab/15035] Excessive symtab expansion setting a breakpoint on foo::bar.
2013-01-18 19:43 [Bug symtab/15035] New: Excessive symtab expansion setting a breakpoint on foo::bar dje at google dot com
@ 2025-02-22 3:20 ` tromey at sourceware dot org
2025-02-22 18:53 ` tromey at sourceware dot org
1 sibling, 0 replies; 3+ messages in thread
From: tromey at sourceware dot org @ 2025-02-22 3:20 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=15035
Tom Tromey <tromey at sourceware dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at sourceware dot org
--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
Both linespec and the parsers should probably try maximal
lookups as opposed to minimal lookups. That is, for
"x::y::z", they should start with the full string. Then
if needed (?) they could try prefixes.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug symtab/15035] Excessive symtab expansion setting a breakpoint on foo::bar.
2013-01-18 19:43 [Bug symtab/15035] New: Excessive symtab expansion setting a breakpoint on foo::bar dje at google dot com
2025-02-22 3:20 ` [Bug symtab/15035] " tromey at sourceware dot org
@ 2025-02-22 18:53 ` tromey at sourceware dot org
1 sibling, 0 replies; 3+ messages in thread
From: tromey at sourceware dot org @ 2025-02-22 18:53 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=15035
--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
For C++ I wonder if there's a case where a maximal lookup
could even "fail", in the sense that a prefix would succeed
instead.
For languages like Ada this can happen because "x.y.z" may
refer to some field "z" of a record "x.y". But in C++
this would be "x::y.z" instead.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-02-22 18:53 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-18 19:43 [Bug symtab/15035] New: Excessive symtab expansion setting a breakpoint on foo::bar dje at google dot com
2025-02-22 3:20 ` [Bug symtab/15035] " tromey at sourceware dot org
2025-02-22 18:53 ` tromey at sourceware dot org
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).