[PATCH] Binutils support for split-dwarf and dwarf-5
Jan Beulich
jbeulich@suse.com
Fri Jun 3 12:04:25 GMT 2022
On 02.06.2022 16:55, Kumar N, Bhuvanendra via Binutils wrote:
> Patch 1/2 inlined:
>
> From 1bda1e144f43d1f41fe30a934ba008561083dc07 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?=E2=80=9Cbhkumarn=E2=80=9D?= Bhuvanendra.KumarN@amd.com<mailto:Bhuvanendra.KumarN@amd.com>
> Date: Thu, 2 Jun 2022 17:44:02 +0530
> Subject: [PATCH] [PATCH 1/2] Binutils support for split-dwarf and dwarf-5.
>
> This fix adds support for split-dwarf and dwarf5, for both gcc and clang.
> There are 2 patches. Basic sections dump like .debug_info.dwo,
> .debug_abbrev.dwo, .debug_str.dwo etc are supported in this patch 1/2.
> But location list and ranges list sections dump with split-dwarf and dwarf5
> are supported in the next patch 2/2.
Just as a remark: "patch 1/2" and "next patch" and alike aren't very
meaningful in commit messages. The individual commits may end up far
apart in the repo.
> --- a/binutils/dwarf.c
> +++ b/binutils/dwarf.c
> @@ -118,6 +118,8 @@ int dwarf_cutoff_level = -1;
> unsigned long dwarf_start_die;
> int dwarf_check = 0;
> +static dwarf_vma str_offsets_base = 0;
> +#define DEBUG_STR_OFFSETS_HEADER_LEN 8
Aiui 8 is correct for 32-bit Dwarf, but 16 would need using for 64-bit.
> @@ -2485,6 +2487,8 @@ read_and_display_attr_value (unsigned long attribute,
> case DW_FORM_GNU_ref_alt:
> case DW_FORM_GNU_strp_alt:
> SAFE_BYTE_GET_AND_INC (uvalue, data, offset_size, end);
> + if (attribute == DW_AT_str_offsets_base)
> + str_offsets_base = uvalue - DEBUG_STR_OFFSETS_HEADER_LEN;
Can this legitimately be stored in a static variable? Don't you need
to collect the value(s) into debug_info_p just like is done for
DW_AT_loclists_base?
> @@ -11889,6 +11895,7 @@ load_separate_debug_files (void * file, const char * filename)
> && load_debug_section (abbrev, file)
> && load_debug_section (info, file))
> {
> + load_debug_section (str_index, file);
What if this fails? Immediately preceding load_debug_section() uses
have their return values checked.
> --- /dev/null
> +++ b/binutils/testsuite/binutils-all/dwo_5.s
> @@ -0,0 +1,257 @@
> + .file "a.c"
> + .text
> +.Ltext0:
> + .globl a
> + .type a, @function
> +a:
> +.LFB0:
> + .file 1 "a.c"
> + .loc 1 1 13
> + .cfi_startproc
> + pushq %rbp
> + .cfi_def_cfa_offset 16
> + .cfi_offset 6, -16
> + movq %rsp, %rbp
> + .cfi_def_cfa_register 6
> + .loc 1 1 22
> + movl $111, %eax
> + .loc 1 1 1
> + popq %rbp
> + .cfi_def_cfa 7, 8
> + ret
> + .cfi_endproc
> +.LFE0:
> + .size a, .-a
> +.Letext0:
> + .section .debug_addr,"",@progbits
> + .long 0xc
> + .value 0x5
> + .byte 0x8
> + .byte 0
> +.Ldebug_addr0:
> + .quad .LFB0
> + .section .debug_info.dwo,"e",@progbits
> +.Ldebug_info0:
> + .long 0x35
> + .value 0x5
> + .byte 0x5
> + .byte 0x8
> + .long .Ldebug_abbrev0
> + .byte 0x46
> + .byte 0x1c
> + .byte 0xf1
> + .byte 0xfb
> + .byte 0xe5
> + .byte 0x96
> + .byte 0x7d
> + .byte 0x2b
> + .uleb128 0x1
> + .uleb128 0x1
> + .byte 0x1d
> + .string "a.c"
> + .uleb128 0
> + .uleb128 0x2
> + .string "a"
> + .byte 0x1
> + .byte 0x1
> + .byte 0x5
> + .long 0x31
> + .uleb128 0
> + .quad .LFE0-.LFB0
> + .uleb128 0x1
> + .byte 0x9c
> + .uleb128 0x3
> + .byte 0x4
> + .byte 0x5
> + .string "int"
> + .byte 0
> + .section .debug_info,"",@progbits
> +.Lskeleton_debug_info0:
> + .long 0x31
> + .value 0x5
> + .byte 0x4
> + .byte 0x8
> + .long .Lskeleton_debug_abbrev0
> + .byte 0x46
> + .byte 0x1c
> + .byte 0xf1
> + .byte 0xfb
> + .byte 0xe5
> + .byte 0x96
> + .byte 0x7d
> + .byte 0x2b
> + .uleb128 0x1
> + .quad .Ltext0
> + .quad .Letext0-.Ltext0
> + .long .Ldebug_line0
> + .long .LASF0
> + .long .LASF1
> + .long .Ldebug_addr0
> + .section .debug_abbrev,"",@progbits
> +.Lskeleton_debug_abbrev0:
> + .uleb128 0x1
> + .uleb128 0x4a
> + .byte 0
> + .uleb128 0x11
> + .uleb128 0x1
> + .uleb128 0x12
> + .uleb128 0x7
> + .uleb128 0x10
> + .uleb128 0x17
> + .uleb128 0x76
> + .uleb128 0xe
> + .uleb128 0x1b
> + .uleb128 0xe
> + .uleb128 0x2134
> + .uleb128 0x19
> + .uleb128 0x73
> + .uleb128 0x17
> + .byte 0
> + .byte 0
> + .byte 0
> + .section .debug_abbrev.dwo,"e",@progbits
> +.Ldebug_abbrev0:
> + .uleb128 0x1
> + .uleb128 0x11
> + .byte 0x1
> + .uleb128 0x25
> + .uleb128 0x1a
> + .uleb128 0x13
> + .uleb128 0xb
> + .uleb128 0x3
> + .uleb128 0x8
> + .uleb128 0x1b
> + .uleb128 0x1a
> + .byte 0
> + .byte 0
> + .uleb128 0x2
> + .uleb128 0x2e
> + .byte 0
> + .uleb128 0x3f
> + .uleb128 0x19
> + .uleb128 0x3
> + .uleb128 0x8
> + .uleb128 0x3a
> + .uleb128 0xb
> + .uleb128 0x3b
> + .uleb128 0xb
> + .uleb128 0x39
> + .uleb128 0xb
> + .uleb128 0x27
> + .uleb128 0x19
> + .uleb128 0x49
> + .uleb128 0x13
> + .uleb128 0x11
> + .uleb128 0x1b
> + .uleb128 0x12
> + .uleb128 0x7
> + .uleb128 0x40
> + .uleb128 0x18
> + .uleb128 0x7a
> + .uleb128 0x19
> + .byte 0
> + .byte 0
> + .uleb128 0x3
> + .uleb128 0x24
> + .byte 0
> + .uleb128 0xb
> + .uleb128 0xb
> + .uleb128 0x3e
> + .uleb128 0xb
> + .uleb128 0x3
> + .uleb128 0x8
> + .byte 0
> + .byte 0
> + .byte 0
> + .section .debug_gnu_pubnames,"",@progbits
> + .long 0x15
> + .value 0x2
> + .long .Lskeleton_debug_info0
> + .long 0x39
> + .long 0x1c
> + .byte 0x30
> + .string "a"
> + .long 0
> + .section .debug_gnu_pubtypes,"",@progbits
> + .long 0x17
> + .value 0x2
> + .long .Lskeleton_debug_info0
> + .long 0x39
> + .long 0x31
> + .byte 0x90
> + .string "int"
> + .long 0
> + .section .debug_aranges,"",@progbits
> + .long 0x2c
> + .value 0x2
> + .long .Lskeleton_debug_info0
> + .byte 0x8
> + .byte 0
> + .value 0
> + .value 0
> + .quad .Ltext0
> + .quad .Letext0-.Ltext0
> + .quad 0
> + .quad 0
> + .section .debug_line,"",@progbits
> +.Ldebug_line0:
> + .section .debug_line.dwo,"e",@progbits
> +.Lskeleton_debug_line0:
> + .long .LELT0-.LSLT0
> +.LSLT0:
> + .value 0x5
> + .byte 0x8
> + .byte 0
> + .long .LELTP0-.LASLTP0
> +.LASLTP0:
> + .byte 0x1
> + .byte 0x1
> + .byte 0x1
> + .byte 0xf6
> + .byte 0xf2
> + .byte 0xd
> + .byte 0
> + .byte 0x1
> + .byte 0x1
> + .byte 0x1
> + .byte 0x1
> + .byte 0
> + .byte 0
> + .byte 0
> + .byte 0x1
> + .byte 0
> + .byte 0
> + .byte 0x1
> + .byte 0x1
> + .uleb128 0x1
> + .uleb128 0x8
> + .uleb128 0x1
> + .string "/tmp"
> + .byte 0x2
> + .uleb128 0x1
> + .uleb128 0x8
> + .uleb128 0x2
> + .uleb128 0xb
> + .uleb128 0x2
> + .string "a.c"
> + .byte 0
> + .string "a.c"
> + .byte 0
> +.LELTP0:
> +.LELT0:
> + .section .debug_str,"MS",@progbits,1
> +.LASF1:
> + .string "/tmp"
> +.LASF0:
> + .string "a.dwo"
> + .section .debug_str_offsets.dwo,"e",@progbits
> + .long 0xc
> + .value 0x5
> + .value 0
> + .long 0
> + .long 0x5
> + .section .debug_str.dwo,"e",@progbits
> + .string "/tmp"
> + .string "GNU C17 10.0.0 20190813 (experimental) -mtune=generic -march=x86-64 -gdwarf-5 -gsplit-dwarf"
> + .ident "GCC: (GNU) 10.0.0 20190813 (experimental)"
> + .section .note.GNU-stack,"",@progbits
I'm a little worried about the maintainability (and reviewability) of
such testcases: This looks to be compiler output, even with non-
essential pieces left in. That's fine in principle, but without any
comments it's close to unreadable. Plus it's then unclear whether the
compiler-generated directives are actually all correct; after all
compilers can also have bugs, and the compiler used wasn't even a
released version, and even quite early a major-10 version.
Jan
More information about the Binutils
mailing list