]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit - gdb/testsuite/ChangeLog-2014-2021
[gdb/symtab] Read CU base address for enqueued CU
authorTom de Vries <tdevries@suse.de>
Mon, 26 Oct 2020 19:28:47 +0000 (20:28 +0100)
committerTom de Vries <tdevries@suse.de>
Mon, 26 Oct 2020 19:28:47 +0000 (20:28 +0100)
commit1c47ec3ee86fc08d120dae7e63cec552fa456912
tree5850ccab904dd7fbeece9879b7835334aca5590f
parent6390859caa7684ff195d57e9f5cc02eae89bdb95
[gdb/symtab] Read CU base address for enqueued CU

Consider the test-case contained in this patch.  It consists of
two CUs:
- cu1, containing a DW_TAG_variable DIE foo
- cu2, containing a DW_TAG_base_type DIE int
where the variable foo has type int, in other words, there's an inter-CU
reference.

When expanding the symtab for cu1, expansion of the symtab for cu2 is
enqueued, and later processed by process_full_comp_unit.  However, processing
of .debug_ranges fails because the range is specified relative to a base
address which is considered not to be present because
!cu->base_address.has_value (), and we run into this case in
dwarf2_ranges_process:
...
      if (!base.has_value ())
        {
          /* We have no valid base address for the ranges
             data.  */
          complaint (_("Invalid .debug_ranges data (no base address)"));
          return 0;
        }
...

Fix this in process_full_comp_unit by setting cu->base_address.

Tested on x86_64-linux.

gdb/ChangeLog:

2020-10-26  Tom de Vries  <tdevries@suse.de>

* dwarf2/read.c (process_full_comp_unit): Call
dwarf2_find_base_address.

gdb/testsuite/ChangeLog:

2020-10-26  Tom de Vries  <tdevries@suse.de>

* gdb.dwarf2/enqueued-cu-base-addr.exp: New file.
gdb/ChangeLog
gdb/dwarf2/read.c
gdb/testsuite/ChangeLog
gdb/testsuite/gdb.dwarf2/enqueued-cu-base-addr.exp [new file with mode: 0644]