Say one compiles a hello.c:
...
$ gcc -g hello.c
...
On openSUSE Leap 15.2 and Tumbleweed, the CU for hello.c is typically not the
first in .debug_info, nor the last, due to presence of debug information in
objects for sources like:
- ../sysdeps/x86_64/start.S
- init.c
- ../sysdeps/x86_64/crti.S
- elf-init.c
- ../sysdeps/x86_64/crtn.S.
On other systems, say ubuntu 18.04.5, the CU for hello.c is typically the
first and the last in .debug_info.
This difference has caused me to find some errors in the dwarf assembly
using openSUSE, that didn't show up on other platforms.
Force the same situation on other platforms by adding a dummy start
and end CU.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-08-22 Tom de Vries <tdevries@suse.de>
PR testsuite/28235
* lib/dwarf.exp (Dwarf::dummy_cu): New proc.
(Dwarf::assemble): Add dummy start and end CU.
}
}
+ # Emit a dummy CU.
+ proc dummy_cu {} {
+ # Generate a CU with default options and empty body.
+ cu {} {
+ }
+ }
+
# The top-level interface to the DWARF assembler.
# FILENAME is the name of the file where the generated assembly
# code is written.
}
set _output_file [open $filename w]
- set _cu_count 0
+ set _cu_count -1
_empty_array _deferred_output
set _defer ""
set _label_num 0
set _debug_addr_index 0
+ # Dummy CU at the start to ensure that the first CU in $body is not
+ # the first in .debug_info.
+ dummy_cu
+
# Not "uplevel" here, because we want to evaluate in this
# namespace. This is somewhat bad because it means we can't
# readily refer to outer variables.
eval $body
+ # Dummy CU at the end to ensure that the last CU in $body is not
+ # the last in .debug_info.
+ dummy_cu
+
_write_deferred_output
catch {close $_output_file}