[committed,gdb/testsuite] Fix maint-expand-symbols-header-file.exp for cc-with-gdb-index

Message ID 159563db-33bc-fb45-c51a-02797c60e857@suse.de
State New
Headers show
Series
  • [committed,gdb/testsuite] Fix maint-expand-symbols-header-file.exp for cc-with-gdb-index
Related show

Commit Message

Tom de Vries April 16, 2020, 6:45 a.m.
[ was: Re: [PATCH][gdb] Expand symbolless symtabs using maint
expand-symtabs ]

On 14-04-2020 15:09, Tom de Vries wrote:
> On 02-04-2020 10:44, Tom de Vries wrote:

>> On 01-04-2020 21:45, Tom Tromey wrote:

>>>>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:

>>>

>>> Tom> When trying to expand the partial symtab for hello.h:

>>> Tom> ...

>>> Tom> $ gdb -batch \

>>> Tom>   -iex "set language c" \

>>> Tom>   a.out \

>>> Tom>   -ex "maint expand-symtabs hello.h" \

>>> Tom>   -ex "maint info psymtabs"

>>> Tom> ...

>>> Tom> we in fact find that the partial symtab has not been expanded:

>>> Tom> ...

>>> Tom>   { psymtab hello.h ((struct partial_symtab *) 0x27cf070)

>>> Tom>     readin no

>>> Tom> ...

>>>

>>> Does this matter, though?

>>> I thought include psymtabs like these were kind of placeholders.

>>>

>>

>> Right, but the includer symtab they're pointing towards are also not

>> expanded.

>>

> 

> I've updated the log message to reflect this, as well as the test-case.

> 

>> Concretely, it does matter for dwarf assembly test-cases, in the sense

>> that this patch allows me to have the symtab effect of setting a

>> breakpoint in a certain file, without actually setting the breakpoint,

>> which means there's no need to flesh out the .debug_line section in

>> detail, or indeed even create the file.

>>

>> [ I mentioned this patch as a prerequisite for a dwarf assembly

>> test-case here :

>> https://sourceware.org/pipermail/gdb-patches/2020-March/167152.html ]

>>

>> Furthermore, I found this problem originally not with include psymtabs,

>> but with this type of one-DIE CUs:

>> ...

>>  <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)

>>     <c>   DW_AT_stmt_list   : 0x0

>>     <10>   DW_AT_low_pc      : 0x400430

>>     <18>   DW_AT_high_pc     : 0x40045b

>>     <20>   DW_AT_name        : ../sysdeps/x86_64/start.S

>>     <24>   DW_AT_comp_dir    : /home/abuild/rpmbuild/BUILD/glibc-2.26/csu

>>     <28>   DW_AT_producer    : GNU AS 2.31.1

>>     <2c>   DW_AT_language    : 32769    (MIPS assembler)

>> ...

>> which I get in every exec on openSUSE Leap 15.1.

>>

>> In that case, the problem means that "maint expand-symtabs" doesn't

>> expand the symtab, in violation of the "maint expand-symtabs"

>> documentation, while also being inconsistent with -readnow which does

>> create a symbolless symtab.

>>

> 

> I've also noted this in the log message.

> 

>> I used the include psymtabs as test-case and running example because it

>> reproduces on all platforms in a standard test-case.

>>

>>> Tom> Fix this by passing a NULL symbol_matcher and lookup_name to

>>> Tom> expand_symtabs_matching in maintenance_expand_symtabs, and skipping the call

>>> Tom> to recursively_search_psymtabs if symbol_matcher == NULL and

>>> Tom> lookup_name == NULL.

>>>

>>> Could this code use map_symtabs_matching_filename instead?

>>>

>>

>> I can see how that would help with "maint expand-symtabs <file>", but

>> still "maint expand-symtabs" would not expand the partial symtab for

>> ../sysdeps/x86_64/start.S.

>>

>> Thanks,

>> - Tom

>>

>>> I guess I'm not super fond of turning the reference arguments to

>>> pointers, unless there's really no other way.

> 

> Unfortunately I don't see another way atm, so I'm committing this as

> attached below.

> 

> [ FWIW, something I'm not very happy with myself is the undoing of the

> micro-optimization of having this outside of the partial symtabs loop:

> ...

>   lookup_name_info lookup_name = lookup_name_in.make_ignore_params ();

> ...

> but I'm not sure how to address that. ]


I somehow forgot the logic behind manually setting the language and how
that is related to indices, so in the committed version I removed the
manual language setting, and did not retest with cc-with-gdb-index, with
a FAIL as result.

This patch fixes that by reinstating the manual language setting.

Committed.

Thanks,
- Tom

Patch

[gdb/testsuite] Fix maint-expand-symbols-header-file.exp for cc-with-gdb-index

With test-case gdb.base/maint-expand-symbols-header-file.exp and target board
cc-with-gdb-index, we have:
...
FAIL: gdb.base/maint-expand-symbols-header-file.exp: \
  verify no symtabs are expanded
...

By default, with partial symbols, we find the main function in the partial
symbols, and derive the initial language setting from that, without expanding
any psymtab.

But that doesn't work with the indices, because the indices don't store the
language with the symbols.  So instead, the main psymtab is expanded to get
the language of main, which causes the FAIL.

Fix this by manually setting the language.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-04-16  Tom de Vries  <tdevries@suse.de>

	* gdb.base/maint-expand-symbols-header-file.exp: Set language before
	loading exec.

---
 gdb/testsuite/gdb.base/maint-expand-symbols-header-file.exp | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.base/maint-expand-symbols-header-file.exp b/gdb/testsuite/gdb.base/maint-expand-symbols-header-file.exp
index f73be404c9..05802b2719 100644
--- a/gdb/testsuite/gdb.base/maint-expand-symbols-header-file.exp
+++ b/gdb/testsuite/gdb.base/maint-expand-symbols-header-file.exp
@@ -18,10 +18,16 @@ 
 
 standard_testfile .c
 
-if {[prepare_for_testing "failed to prepare" $testfile \
+if {[build_executable "failed to prepare" $testfile \
 	 $srcfile {debug nowarnings}]} {
     return -1
 }
+clean_restart
+
+# Make sure that no symtabs are expanded, by setting language before
+# loading exec.
+gdb_test_no_output "set language c"
+gdb_load ${binfile}
 
 set test "verify no symtabs are expanded"
 if { [readnow] } {