[Bug c++/16253] Cannot print an enum var with the same name as tag

["dje at google dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16253

dje at google dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |dje at google dot com
         Resolution|FIXED                       |---

--- Comment #7 from dje at google dot com ---
Alas the patch introduces a massive perf regression in one of my perf tests.

Using my standard monster testcase, doing "info fun ^foo::(anonymous
namespace)" goes from about a minute to an untold number of minutes (expected
to be in the thousands :-)).

.gdb_index has this for int64:

[1476052] int64:
        2 [static, type]
        4 [static, type]
        5 [static, type]
        ...

There are 10K such entries.

The output of "info fun ..." includes "int64" so cp_canonicalize_string_full
("int64") is called.

cp-support.c:inspect_type first tries to look up the symbol in STRUCT_DOMAIN,
and then in VAR_DOMAIN.  The problem is that there is insufficient info in the
index to know a lookup in STRUCT_DOMAIN will fail, so dw2_symtab_iter_next will
blindly return every entry in the index, which will cause every CU to be
expanded.  Later, when we do the lookup in the symtab, the domains won't match
(int64 is in VAR_DOMAIN) so the lookup will fail and we'll try the next entry
in the index ...

Later, inspect_type will try VAR_DOMAIN:

    if (current_language->la_language == language_cplus)
      sym = lookup_symbol (name, 0, STRUCT_DOMAIN, 0);
    if (sym == NULL)
      sym = lookup_symbol (name, 0, VAR_DOMAIN, NULL);

but that's only after gdb has expanded the debug info for 10K CUs.
Ugh.

One solution is to encode the STRUCT_DOMAIN/VAR_DOMAIN attribute in the index.
We should first see what's involved in generating this, and whether gold can.

Another solution would be for symbol lookup to stop iterating over every CU
looking for static symbols (or at least not do that until the very VERY end).
If I'm in CU foo.o I should expect to not get the definition of "static" symbol
baz in bar.o.  This also ties in with the currently broken lookup of "int": we
should search the current CU, then the arch defaults, then maybe as a last
resort every CU.  The performance cost of these "last resort" lookups on big
programs has soured me on doing that by default though.

In the case of "info fun ..." where cp_canonicalize_string_full isn't passed a
CU (so how can it know which CU to look in for static symbols), we need to
start passing it one (and similarly throughout gdb).

I'm going to check if there's an existing PR for this perf problem, and open a
new one if not.

I think this is a blocker for 7.8.

-- 
You are receiving this mail because:
You are on the CC list for the bug.