Re: .eh_frame

[Jason Merrill <jason at cygnus dot com>]

>>>>> Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz> writes:

>         .uaword .LLEFDE1-.LLSFDE1       ! FDE Length
> .LLSFDE1:
>         .uaxword        __FRAME_BEGIN__ ! FDE CIE offset
>         .uaxword        .LLFB1  ! FDE initial location
>         .uaxword        .LLFE1-.LLFB1   ! FDE address range
>         .byte   0x4     ! DW_CFA_advance_loc4
>         .uaword .LLCFI0-.LLFB1
>         .byte   0xd     ! DW_CFA_def_cfa_register
>         .byte   0x1e    ! ULEB128 0x1e
>         .byte   0x2d    ! DW_CFA_GNU_window_save
>         .byte   0x9     ! DW_CFA_register
>         .byte   0x65    ! ULEB128 0x65
>         .byte   0x1f    ! ULEB128 0x1f
>         .align 8
> .LLEFDE1:

> Now, this is clearly wrong - .LLSFDE1 is for sure not 8 aligned and thus the
> 64bit relocation at that address bumps.

No, it's not wrong; that's why we use .uaxword.  The assembler should
generate an unaligned reloc.

> Also, I'm not sure if not aligning .LLCFI0-.LLFB1 is the intention, but
> it will work, as that is a constant, unlike __FRAME_BEGIN__ and .LLFB1.
> Is it fault in sp64-elf.h and I need to redefine ASM_OUTPUT_DWARF_DELTA
> (won't it break something?) or should dwarf2out align it itself?  Or is
> it a bug in the linker in that it should have some special relocation
> type for unaligned 64bit relocations (don't have the ABI specs yet).

ELF targets should support unaligned relocs.  They must if they want to
support DWARF.

7.24 Dependencies
The debugging information in this format is intended to exist in the
.debug_abbrev, .debug_aranges, .debug_frame, .debug_info, .debug_line,
.debug_loc, .debug_macinfo, .debug_pubnames and .debug_str sections of an
object file. The information is not word-aligned, so the assembler must
provide a way for the compiler to produce 2-byte and 4-byte quantities
without alignment restrictions, and the linker must be able to relocate a
4-byte reference at an arbitrary alignment. In target architectures with
64-bit addresses, the assembler and linker must similarly handle 8-byte
references at arbitrary alignments.

> Also, may I wonder why FDE CIE offset is repeated in every FDE

So that FDEs can refer to different CIEs.  This leaves room for linker
optimizations.

> it could be just a relative offset and thus not 'cause any relocation?

I suppose it could.

Jason