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;
}
next 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