Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Cc: Tom Tromey <tom@tromey.com>
Subject: [PATCH][gdb] Fix missing symtab includes
Date: Fri, 27 Mar 2020 21:49:50 +0100	[thread overview]
Message-ID: <20200327204948.GA23365@delia> (raw)

Hi,

Consider hello.h:
...
 inline static const char*
 foo (void)
 {
   return "foo";
 }
...
and hello.c:
...
 #include <stdio.h>
 #include "hello.h"

 int
 main (void)
 {
   printf ("hello: %s\n", foo ());
   return 0;
 }
...
compiled with -g, and dwz-compressed:
...
$ gcc -g hello.c
$ dwz a.out
...

When breaking on foo and printing the symbol tables, we have two includes for
the hello.c compunit_symtab, representing two imported partial units:
...
$ gdb -iex "set language c" -batch a.out -ex "b foo" -ex "maint info symtabs"
Breakpoint 1 at 0x40050b: file hello.h, line 4.
  ...
  { ((struct compunit_symtab *) 0x38fa890)
    debugformat DWARF 2
    producer GNU C11 7.5.0 -mtune=generic -march=x86-64 -g
    dirname /data/gdb_versions/devel
    blockvector ((struct blockvector *) 0x39af9f0)
    user ((struct compunit_symtab *) (null))
    ( includes
      ((struct compunit_symtab *) 0x39afb10)
      ((struct compunit_symtab *) 0x39b00c0)
    )
        { symtab hello.c ((struct symtab *) 0x38fa940)
          fullname (null)
          linetable ((struct linetable *) 0x39afa80)
        }
...

But if we instead break on the same location using a linespec, the includes
are gone:
...
$ gdb -iex "set language c" -batch a.out -ex "b hello.h:4" -ex "maint info symtabs"
Breakpoint 1 at 0x40050b: file hello.h, line 4.
  ...
  { ((struct compunit_symtab *) 0x2283500)
    debugformat DWARF 2
    producer GNU C11 7.5.0 -mtune=generic -march=x86-64 -g
    dirname /data/gdb_versions/devel
    blockvector ((struct blockvector *) 0x23086c0)
    user ((struct compunit_symtab *) (null))
        { symtab hello.c ((struct symtab *) 0x22835b0)
          fullname (null)
          linetable ((struct linetable *) 0x2308750)
        }
...

The includes are calculated by process_cu_includes in gdb/dwarf2/read.c.

In the case of "b foo":
- the hello.c partial symtab is found to contain foo
- the hello.c partial symtab is expanded using psymtab_to_symtab
- psymtab_to_symtab calls dwarf2_psymtab::read_symtab
- dwarf2_psymtab::read_symtab calls dwarf2_psymtab::expand_psymtab
- dwarf2_psymtab::read_symtab calls process_cu_includes, and we have the
  includes

In the case of "b hello.h:4":
- the hello.h partial symtab is found to represent hello.h
- the hello.h partial symtab is expanded using psymtab_to_symtab
- psymtab_to_symtab calls dwarf2_include_psymtab::read_symtab
- dwarf2_include_psymtab::read_symtab calls
  dwarf2_include_psymtab::expand_psymtab
- dwarf2_include_psymtab::expand_psymtab calls
  partial_symtab::read_dependencies
- partial_symtab::read_dependencies calls dwarf2_psymtab::expand_psymtab
  for partial symtab hello.c
- the hello.c partial symtab is expanded using dwarf2_psymtab::expand_psymtab
- process_cu_includes is never called

Fix this by making sure in dwarf2_include_psymtab::expand_psymtab that
read_symtab rather than expand_symtab is called for the hello.c partial
symtab.

Tested on x86_64-linux, with native, and target board cc-with-dwz and
cc-with-dwz-m.

OK for trunk?

Thanks,
- Tom

[gdb] Fix missing symtab includes

gdb/ChangeLog:

2020-03-27  Tom de Vries  <tdevries@suse.de>

	PR symtab/25718
	* dwarf2/read.c (dwarf2_include_psymtab::expand_psymtab): Call
	read_symtab instead of expand_symtab for dependency.

---
 gdb/dwarf2/read.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 2465ecebe3..fb90a04061 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -5840,7 +5840,14 @@ struct dwarf2_include_psymtab : public partial_symtab
       return;
     /* It's an include file, no symbols to read for it.
        Everything is in the parent symtab.  */
-    read_dependencies (objfile);
+
+    /* Make sure that we call read_symtab rather than just expand_symtab,
+       otherwise process_cu_includes is never called, and the expanded symtab
+       will not have the correct value for the includes field (note:
+       confusingly, the mentioned includes field is related to imported units,
+       and has no relation to include as used in 'dwarf2_include_psymtab').  */
+    if (!dependencies[0]->readin_p ())
+      dependencies[0]->read_symtab (objfile);
     m_readin = true;
   }
 


             reply	other threads:[~2020-03-27 20:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-27 20:49 Tom de Vries [this message]
2020-03-28 16:32 ` Simon Marchi
2020-03-28 17:24   ` Tom de Vries
2020-03-29 15:39     ` Simon Marchi
2020-03-29 15:56       ` Tom de Vries
2020-03-29 21:44         ` Simon Marchi
2020-03-30 17:42           ` Tom de Vries
2020-04-14 13:31             ` Tom de Vries
2020-03-28 19:08 ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200327204948.GA23365@delia \
    --to=tdevries@suse.de \
    --cc=gdb-patches@sourceware.org \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox