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)
        {
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.