Re: Type-lookup by name for type in namespace fails with -fdebug-types-section after 93b8bea
Sterling Augustine via Gdb <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <CAEG7qUzt5dTbDit2qmi06T-9_6rdv8=Zu3KoXbdYr1jWDyanSw@mail.gmail.com> |
On Mon, Mar 16, 2020 at 10:16 AM Sterling Augustine <[email protected]> wrote: > > Hi Tom, > > We have found a strange error with -fdebug-types-section, and as best I can tell, your commit 93b8bea4143cafae79076076c64aaa4c46a9b73c is the culprit, although I don't understand how or why. > > In any event, before this change, the test-case below works fine, and after it, lookup of a type in a namespace by name fails. In particular, "ptype hide::Bar" should find the type. But it fails both inside python with gdb.lookup_type and with normal commands. > > Any idea what is happening? Reproducer follows. > > $ g++ -v > ... > gcc version 9.2.1 20191102 (Debian 9.2.1-17) > $ cat b.cpp > namespace hide { struct Bar { int y; }; } > struct Foo { hide::Bar* b; }; > > inline void x() { hide::Bar b; } > > static Foo aFoo; > > void * f() { > return aFoo.b; > } > > int main() { > f(); > return 0; > } > $ g++ -fdebug-types-section b.cpp -g > $ ./build/gdb/gdb -ex "b f" -ex run -ex "ptype hide::Bar" ./a.out > ... > GNU gdb (GDB) 8.2.50.20180720-git > ... > Reading symbols from ./a.out...done. > Breakpoint 1 at 0x1129: file b.cpp, line 11. > Starting program: /usr/local/google/home/saugustine/gdb/a.out > > Breakpoint 1, Python Exception <type 'exceptions.NameError'> Installation error: gdb.execute_unwinders function is missing: > f () at b.cpp:11 > 11 return aFoo.b; > No symbol "Bar" in namespace "hide". > (gdb) I have found the source of this problem. The patch I identified above relies on start_symtab to set list_in_scope. For type units, setup_type_unit_groups ordinarily calls start_symtab. However, when setup_type_unit_groups is called the second time (ie, first_time ends up false), setup_type_unit_groups doesn't call start_symtab, but does a small amount of housekeeping to recover the previously started symtab. This patch sets list_in_scope in addition to the other housekeeping it does, and this fixes the problem. OK for trunk? diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 186660bf9f..23dee0f503 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,7 @@ +2020-03-24 Sterling Augustine <[email protected]> + + * dwarf2/read.c (setup_type_unit_groups): Set list_in_scope. + 2020-03-20 Tom Tromey <[email protected]> * dwarf2/loc.h (dwarf2_evaluate_property): Make "addr_stack" diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index 0e879e08a0..65afb43b04 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -10954,6 +10954,7 @@ dwarf2_cu::setup_type_unit_groups (struct die_info *die) compunit_language (cust), 0, cust)); + list_in_scope = get_builder ()->get_file_symbols (); auto &file_names = line_header->file_names (); for (i = 0; i < file_names.size (); ++i) {