This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug symtab/17387] New: missing entries for multiple different typedefs with same name in .gdb_index


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

            Bug ID: 17387
           Summary: missing entries for multiple different typedefs with
                    same name in .gdb_index
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: dje at google dot com

dwarf2read.c:write_psymbols only writes out one copy of each psym here:

      /* Only add a given psymbol once.  */
      slot = htab_find_slot (psyms_seen, psym, INSERT);
      if (!*slot)

which is in and of itself not a bad thing.  For some psyms we only want one
copy.

However, the typedef "mytype" in the attached example is defined in multiple
CUs and has different definitions in each.

This causes the output of "info types mytype" to be different with/without
gdb-generated .gdb_index:

Without gdb-generated .gdb_index:

bash$ gdb a.out
(gdb) info types mytype
All types matching regular expression "mytype":

File a.cc:
typedef A mytype;

File b.cc:
typedef A mytype;

File c.cc:
typedef A::B mytype;

With gdb-generated .gdb_index:

bash$ gdb a.out.2
(gdb) info types mytype
All types matching regular expression "mytype":

File a.cc:
typedef A mytype;

Perhaps a minor issue.  I'm not sure (yet) if there are more serious issues.
Since typedefs have static scope, and since we'll in general want to first look
in the current static scope before looking elsewhere (which we don't always do
right now), it might be that this will remain a minor issue.

Still, it's a bit odd: Why put any statically scoped symbols in the index then?
[and perhaps instead require the user to somehow always specify the desired CU:
e.g. by $pc or by file name or whatever]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]