https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81361
--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> I did this and there's nothing interesting revealed - everything
> consistently gives the same output (and dwarfdump --verify claims it's
> valid).
Not for me though. Here's the output on the C++ testcase:
(botcazou@goole) ~ $ dwarfdump t.o --eh --verify
----------------------------------------------------------------------
File: t.o (x86_64)
----------------------------------------------------------------------
Verifying EH Frame... error: FDE row for address 0xffffffffffffffe2 is not in
the FDE address range.
0x00000050: FDE
length: 0x0000002c
CIE_pointer: 0x00000000
start_addr: 0x0000000000000054 ___cold_sect_of__main + 0x00000008
range_size: 0x0000000000000022 (end_addr = 0x0000000000000076)
LSDA address: 0x00000000000000a0
Instructions: 0x0000000000000054: CFA=rsp+8 rip=[rsp]
DW_CFA_set_loc (0xffffffffffffff8e)
DW_CFA_def_cfa_offset (16)
DW_CFA_offset (rbx, -16)
DW_CFA_nop
DW_CFA_nop
0xffffffffffffffe2: CFA=rsp+16 rbx=[rsp] rip=[rsp+8]
error: FDE row for address 0xffffffffffffff82 is not in the FDE address range.
error: FDE row for address 0xffffffffffffffb2 is not in the FDE address range.
0x000000a8: FDE
length: 0x00000034
CIE_pointer: 0x00000000
start_addr: 0x000000000000004c ___cold_sect_of__main
range_size: 0x0000000000000031 (end_addr = 0x000000000000007d)
LSDA address: 0x00000000000000f0
Instructions: 0x000000000000004c: CFA=rsp+8 rip=[rsp]
DW_CFA_set_loc (0xffffffffffffff36)
DW_CFA_def_cfa_offset (16)
0xffffffffffffff82: CFA=rsp+16 rip=[rsp+8]
DW_CFA_advance_loc4 (48)
DW_CFA_def_cfa_offset (8)
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
0xffffffffffffffb2: CFA=rsp+8 rip=[rsp]
3 errors found in EH frame for t.o (x86_64).
But I have an error with the fixed compiler too:
(botcazou@goole) ~ $ dwarfdump t.o --eh --verify
----------------------------------------------------------------------
File: t.o (x86_64)
----------------------------------------------------------------------
Verifying EH Frame...
error: 0x00000050: FDE - address range overlaps with previous FDE:
0x000000a8: FDE
length: 0x0000002c
CIE_pointer: 0x00000000
start_addr: 0x000000000000004c ___cold_sect_of__main
range_size: 0x0000000000000031 (end_addr = 0x000000000000007d)
LSDA address: 0x00000000000000f0
0x00000050: FDE
length: 0x0000002c
CIE_pointer: 0x00000000
start_addr: 0x0000000000000054 ___cold_sect_of__main + 0x00000008
range_size: 0x0000000000000022 (end_addr = 0x0000000000000076)
LSDA address: 0x00000000000000a0
1 errors found in EH frame for t.o (x86_64).
although this yields a working executable.
> There's one point that I'm pursuing, which is that some relocations are
> elided from mach-o objects, where the linker can figure out the right result
> without needing one. So it could be an oversight, or a ld64 bug too. Since
> Darwin is now using .cfi_xxxx there's probably not much testing of the DWARF
> stuff outside GCC use.
Switching to the CFI asm directives is indeed a workaround.
> I also have some patches to enable .cfi_xxxx in Darwin GCC, but need to
> rebase them to current trunk. I guess the hard thing at the moment is to
> know what the true intention was and therefore which component is buggy.
Not clear at this point, but the assembler seems to be a good candidate.
