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

["keiths at redhat dot com" <sourceware-bugzilla@sourceware.org>]

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

Keith Seitz <keiths at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |keiths at redhat dot com
           Assignee|unassigned at sourceware dot org   |keiths at redhat dot com

--- Comment #2 from Keith Seitz <keiths at redhat dot com> ---
This is happening because of the function symbol_matches_domain, which was
introduced by:

commit 5eeb2539423ce5e7241bce403f48b8babb3670b0
Author: Aleksandar Ristovski <aristovski@qnx.com>
Date:   Mon May 5 14:37:32 2008 +0000

        * ada-lang.c: Update throughout to use symbol_matches_domain
        instead of matching the symbol domain explictly.
        * dwarf2read.c (add_partial_symbol): Do not add new psym for
        STRUCT_DOMAIN. Make sure you recognize c++ struct and java and ada
        class as typedefs. See lookup_partial_symbol function.
        (new_symbol): Similar to add_partial_symbol, do not create
        symbol for the typedef. See lookup_block_symbol.
        * symtab.c (symbol_matches_domain): New function, takes care
        of dual meaning of STRUCT_DOMAIN symbol for c++, ada and java.
        (lookup_partial_symbol): Use symbol_matches_domain to see if the
        found psym domain matches the given domain.
        (lookup_block_symbol): Likewise.

The parsers all lookup names from the input using searches in VAR_DOMAIN.
However, because of the above patch, any symbol in STRUCT_DOMAIN will also
match. As a result, lookup_block_symbol returns the type named "e" instead of
the variable named "e".

>From the comments in this patch (there is no public discussion that I could
find), I believe I understand why it was introduced, but I don't think this
solution was appropriate. I would have thought it would be easier (and more
correct) to either add an explicit typedef during symbol reading or search
VAR_DOMAIN and STRUCT_DOMAIN where appropriate. The only real solution is the
later, since the former will cause name collisions in VAR_DOMAIN.

As it is, I do not think this non-determinant behavior is correct. This will
randomly "hide" variables and types of the same name (depending on where they
are in the symbol table).

There are 183 places where VAR_DOMAIN is mentioned in the source. All need to
be checked. This may take a fair amount of time. If you despearately need a
workaround for c/c++/java (all DWARF), I can send you the work-in-progress
patch for c/c++/java (no test suite regressions). Send me a private email.

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