Re: [PATCH v2 00/42] Share DWARF partial symtabs between objfiles

[Tom de Vries <tdevries@suse.de>]

On 29-05-2020 12:23, Tom de Vries wrote:
> On 27-05-2020 17:51, Simon Marchi wrote:
>> On 2020-05-27 10:53 a.m., Simon Marchi wrote:
>>> I added another patch to the series, see here:
>>>
>>>   https://sourceware.org/pipermail/gdb-patches/2020-May/169065.html
>>>
>>> The gdb.base/infcall-nested-structs-c.exp / gdb.base/infcall-nested-structs-c++.exp failures
>>> just appeared to be intermittent failures in the end.  So I think that with this last patch,
>>> the series would be good to go.
>>>
>>> Simon
>>>
>>
>> All right, the series is now pushed!  With such a change, I do expect some things to break,
>> please let me know if you see some unexpected behavior chgange following this.
>>
> 
> Hi Simon,
> 
> I'm working on enabling the .gdb_index for ada, and after rebasing that
> patch series to recent master I ran into a failure with target board
> cc-with-gdb-index I thought I hadn't seen before, in
> gdb.ada/mi_catch_assert.exp and a few more similar ada test-case.
> 
> I managed to minimize and de-mi the failure to:
> ...
> $ cat cmd.gdb
> file
> /data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.ada/mi_catch_assert/bla
> file
> /data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.ada/mi_catch_assert/bla
> tbreak main
> run
> catch assert
> cond 2 Global_Var = 2
> continue
> $ gdb -batch -ex "set sysroot" -x=cmd.gdb
> Temporary breakpoint 1 at 0x401f39: file
> /data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.ada/mi_catch_assert/b~bla.adb,
> line 132.
> 
> Temporary breakpoint 1, main (argc=1, argv=0x7fffffffdb98,
> envp=0x7fffffffdba8) at
> /data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.ada/mi_catch_assert/b~bla.adb:132
> 132           Ensure_Reference : aliased System.Address :=
> Ada_Main_Program_Name'Address;
> Catchpoint 2: failed Ada assertions
> 
> Catchpoint 2, failed assertion at <__gnat_debug_raise_assert_failure> ()
> at s-excdeb.adb:64
> 64      s-excdeb.adb: Bestand of map bestaat niet.
> ...
> while the expected output is:
> ...
> Catchpoint 2, failed assertion at 0x000000000040200a in bla () at
> /data/gdb_versions/devel/binutils-gdb.git/gdb/testsuite/gdb.ada/mi_catch_assert/bla.adb:32
> 32            pragma Assert (Global_Var = 1, "Error #2"); -- STOP
> ...
> 
> Seeing the repetition of file command in the cmd.gdb file (and how
> commenting out one of them made the test pass), I started suspecting
> this patch series, and wondered if I could reproduce the same or similar
> problems on master using a test-suite hack:
> ...
> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> index 444cea01c3..fa2a999525 100644
> --- a/gdb/testsuite/lib/gdb.exp
> +++ b/gdb/testsuite/lib/gdb.exp
> @@ -4823,7 +4823,12 @@ proc gdb_load_shlib { file } {
>  #
>  proc gdb_load { arg } {
>      if { $arg != "" } {
> -       return [gdb_file_cmd $arg]
> +       set res [gdb_file_cmd $arg]
> +       if { $res != 0 } {
> +           return $res
> +       }
> +       set res [gdb_file_cmd $arg]
> +       return $res
>      }
>      return 0
>  }
> ...
> 
> And indeed, quite a few failures showed up.  I picked one:
> gdb.base/langs.exp.
> 
> So, on master, after this patch series, with target board
> cc-with-gdb-index, we have:
> ...
> Running /data/gdb_versions/devel/src/gdb/testsuite/gdb.base/langs.exp ...
> FAIL: gdb.base/langs.exp: up to foo in langs.exp
> FAIL: gdb.base/langs.exp: show language at foo in langs.exp
> FAIL: gdb.base/langs.exp: up to cppsub_ in langs.exp
> FAIL: gdb.base/langs.exp: show language at cppsub_ in langs.exp
> FAIL: gdb.base/langs.exp: up to fsub in langs.exp
> FAIL: gdb.base/langs.exp: show language at fsub in langs.exp
> 
>                 === gdb Summary ===
> 
> # of expected passes            10
> # of unexpected failures        6
> ...
> while with native we have:
> ...
> Running /data/gdb_versions/devel/src/gdb/testsuite/gdb.base/langs.exp ...
> 
>                 === gdb Summary ===
> 
> # of expected passes            16
> ...
> 
> Before this patch series, the test-case passes without any FAILs with
> target board cc-with-gdb-index.

With the same test-suite hack in place, we have on master with native:
...
Running
/data/gdb_versions/devel/src/gdb/testsuite/gdb.base/index-cache.exp ...
ERROR: Couldn't load
/data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache,
other program already loaded (timeout).
FAIL: gdb.base/index-cache.exp: test_cache_enabled_miss: check
index-cache stats (GDB internal error)
ERROR: Couldn't load
/data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache,
other program already loaded (timeout).
...

First sign of trouble, an assert:
...
(gdb) kill^M
The program is not being run.^M
(gdb) file
/data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache^M
Reading symbols from
/data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache...^M
(gdb) kill^M
The program is not being run.^M
(gdb) file
/data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache^M
Load new symbol table from
"/data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache"?
(y or n) y^M
Reading symbols from
/data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/index-cache/index-cache...^M
/data/gdb_versions/devel/src/gdb/dwarf2/read.c:2546: internal-error:
void create_cus_from_index(dwarf2_per_bfd*, const gdb_byte*,
offset_type, const gdb_byte*, offset_type): Assertion
`per_bfd->all_comp_units.empty ()' failed.^M
...

Thanks,
- Tom