From: Eric Botcazou <ebotcazou@adacore.com>
To: Jonathan Larmour <jifl@ecoscentric.com>
Cc: binutils@sources.redhat.com, Alan Modra <amodra@bigpond.net.au>
Subject: Re: gc sections and .eh_frame
Date: Fri, 10 Jun 2005 15:13:00 -0000 [thread overview]
Message-ID: <200506101712.36920.ebotcazou@adacore.com> (raw)
In-Reply-To: <42A9AAE0.9030209@eCosCentric.com>
> > 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
next prev parent reply other threads:[~2005-06-10 15:13 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-07 17:48 Jonathan Larmour
2005-06-07 18:00 ` Eric Botcazou
2005-06-07 18:11 ` Jonathan Larmour
2005-06-08 2:09 ` Alan Modra
2005-06-08 11:13 ` Jonathan Larmour
2005-06-08 19:10 ` Richard Henderson
2005-06-08 19:29 ` Jonathan Larmour
2005-06-08 19:32 ` Richard Henderson
2005-06-08 21:36 ` Jonathan Larmour
2005-06-08 22:02 ` Richard Henderson
2005-06-09 10:33 ` Jonathan Larmour
2005-06-09 11:38 ` Eric Botcazou
2005-06-09 12:07 ` Jonathan Larmour
2005-06-09 12:49 ` Alan Modra
2005-06-09 13:02 ` Eric Botcazou
2005-06-09 13:50 ` Jonathan Larmour
2005-06-09 14:22 ` Eric Botcazou
2005-06-09 14:33 ` Jonathan Larmour
2005-06-10 4:23 ` Alan Modra
2005-06-10 6:46 ` Eric Botcazou
2005-06-10 11:49 ` Jonathan Larmour
2005-06-10 11:55 ` Eric Botcazou
2005-06-10 12:09 ` Alan Modra
2005-06-10 12:51 ` Jonathan Larmour
2005-06-10 13:44 ` Eric Botcazou
2005-06-10 14:26 ` Jonathan Larmour
2005-06-10 14:50 ` Eric Botcazou
2005-06-10 14:58 ` Jonathan Larmour
2005-06-10 15:13 ` Eric Botcazou [this message]
2005-06-22 11:46 ` Jonathan Larmour
2005-06-25 17:28 ` Alan Modra
2005-06-27 11:56 ` Eric Botcazou
2005-06-28 2:58 ` Alan Modra
2005-06-28 7:40 ` Eric Botcazou
2005-06-28 11:42 ` Alan Modra
2005-06-28 11:58 ` Eric Botcazou
2005-06-29 1:24 ` Alan Modra
2005-06-29 6:52 ` Eric Botcazou
2005-06-29 12:45 ` Jonathan Larmour
2005-06-29 13:54 ` Alan Modra
2005-06-29 22:31 ` Jonathan Larmour
2005-06-30 22:28 ` Alan Modra
2005-07-01 13:31 ` Jonathan Larmour
2005-07-04 4:50 ` Alan Modra
2005-07-04 10:55 ` Jonathan Larmour
2005-07-26 11:30 ` Alan Modra
2005-07-26 12:05 ` Alan Modra
2005-08-25 0:06 ` Jim Blandy
2005-08-25 0:48 ` Alan Modra
2005-06-10 13:35 ` Eric Botcazou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200506101712.36920.ebotcazou@adacore.com \
--to=ebotcazou@adacore.com \
--cc=amodra@bigpond.net.au \
--cc=binutils@sources.redhat.com \
--cc=jifl@ecoscentric.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).