This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: gc sections and .eh_frame
> > Thanks for confirming. However I think I've grasped Alan's remark and we
> > indeed risk marking all the functions in a given input file if it happens
> > to contain no EH tables because its functions don't need them.
>
> Can that really happen in practice? Doesn't that mean having a .eh_frame
> input section present and (on non-powerpc targets) no .gcc_except_frame?
Yes, that can happen if no functions in the file use EH constructs, which is
not uncommon I think. For example in Ada:
with U;
procedure Ma is
i : Integer := 10;
begin
U.Used (i);
end Ma;
.file "ma.adb"
.section .rodata
.LC0:
.string "ma.adb"
.zero 1
.section .text._ada_ma,"ax",@progbits
.globl _ada_ma
.type _ada_ma, @function
_ada_ma:
.LFB2:
pushl %ebp
.LCFI0:
movl %esp, %ebp
.LCFI1:
subl $8, %esp
.LCFI2:
movl $10, -4(%ebp)
subl $12, %esp
cmpl $0, -4(%ebp)
js .L4
cmpl $10, -4(%ebp)
jg .L4
jmp .L2
.L4:
subl $12, %esp
pushl $5
pushl $.LC0
.LCFI3:
call __gnat_rcheck_11
.L2:
movl -4(%ebp), %eax
pushl %eax
.LCFI4:
call u__used
addl $16, %esp
movl %eax, -4(%ebp)
leave
ret
.LFE2:
.size _ada_ma, .-_ada_ma
.section .eh_frame,"a",@progbits
.Lframe1:
.long .LECIE1-.LSCIE1
.LSCIE1:
.long 0x0
.byte 0x1
.string "zP"
.uleb128 0x1
.sleb128 -4
.byte 0x8
.uleb128 0x5
.byte 0x0
.long __gnat_eh_personality
.byte 0xc
.uleb128 0x4
.uleb128 0x4
.byte 0x88
.uleb128 0x1
.align 4
.LECIE1:
.LSFDE1:
.long .LEFDE1-.LASFDE1
.LASFDE1:
.long .LASFDE1-.Lframe1
.long .LFB2
.long .LFE2-.LFB2
.uleb128 0x0
.byte 0x4
.long .LCFI0-.LFB2
.byte 0xe
.uleb128 0x8
.byte 0x85
.uleb128 0x2
.byte 0x4
.long .LCFI1-.LCFI0
.byte 0xd
.uleb128 0x5
.byte 0x4
.long .LCFI3-.LCFI1
.byte 0x2e
.uleb128 0x14
.byte 0x4
.long .LCFI4-.LCFI3
.byte 0x2e
.uleb128 0x10
.align 4
.LEFDE1:
.section .note.GNU-stack,"",@progbits
.ident "GCC: (GNU) 3.4.5 20050607 (prerelease)"
--
Eric Botcazou