From: Iain Sandoe <developer@sandoe-acoustics.co.uk>
To: Anthony Green <green@moxielogic.com>
Cc: Mike Stump <mrs@gcc.gnu.org>,
gcc-patches Patches <gcc-patches@gcc.gnu.org>,
libffi-discuss@sourceware.org
Subject: Re: [patch, libffi] Sync merge libffi
Date: Fri, 09 Mar 2012 12:46:00 -0000 [thread overview]
Message-ID: <32A48973-1E73-41B1-9037-AE857B097952@sandoe-acoustics.co.uk> (raw)
In-Reply-To: <4F53DC89.7000901@moxielogic.com>
[-- Attachment #1: Type: text/plain, Size: 2263 bytes --]
Hello Anthony,
On 4 Mar 2012, at 21:20, Anthony Green wrote:
> The attached patch includes changes that have been reviewed,
> approved and merged into the stand-alone libffi release tree**.
This hunk (and an identical change in src/powerpc/darwin.S) ..
Index: src/powerpc/darwin_closure.S
===================================================================
--- src/powerpc/darwin_closure.S (revision 184894)
+++ src/powerpc/darwin_closure.S (working copy)
@@ -484,7 +484,7 @@
.byte EH_DATA_ALIGN_FACT ; sleb128 -4; CIE Data Alignment Factor
.byte 0x41 ; CIE RA Column
.byte 0x1 ; uleb128 0x1; Augmentation size
- .byte 0x90 ; FDE Encoding (indirect pcrel)
+ .byte 0x10 ; FDE Encoding (indirect pcrel)
.byte 0xc ; DW_CFA_def_cfa
.byte 0x1 ; uleb128 0x1
.byte 0x0 ; uleb128 0x0
.. appear to be incomplete - they change the FDE encoding - without
changing the way in which the information is provided (and the
parenthesized portion of the comment is now misleading).
Consequently, unwinding through libffi for m32/m64 powerpc-darwin is
not working on trunk at present which causes fails in libffi.special/
special.exp (and also causes some additional fails for libjava).
===
Reverting the hunks is one possibility; however the use of indirect-
pcrel is somewhat out-of-line with what the system compiler produces
for FDE encoding (although it is the preferred method for personality
routine encoding)...
... so the following patch modifies the provided data to use just
pcrel (as per the usual output of the system gcc-4.2.1).
I have tested this on a quad G5 running darwin9
libffi/libjava: \{,-mmacosx-version-min=10.4\}\{-m32,-m64\}
The patch restores libffi/libjava to the pre-merge results.
[one new libffi test - err_bad_abi.c - is also failing on trunk for
ppc-darwin, but that's to be investigated separately].
Mike, do you know any special reason that indirect-pcrel was being
used there?
.. or, is this OK for trunk?
Iain
libffi:
* src/powerpc/darwin_closure.S (EH_FRAME_LABEL): New.
Remove indirect reference for Lstartcode. Change comment on FDE
encoding. Use amended EH_FRAME_LABEL for CIE offset.
Adjust initial location to use PCrel, and no indirection.
* src/powerpc/darwin.S: Likewise.
[-- Attachment #2: 185095-libffi-unwind-a.txt --]
[-- Type: text/plain, Size: 2801 bytes --]
Index: libffi/src/powerpc/darwin_closure.S
===================================================================
--- libffi/src/powerpc/darwin_closure.S (revision 185095)
+++ libffi/src/powerpc/darwin_closure.S (working copy)
@@ -466,14 +466,10 @@ Lendcode:
/* 176, 400 */
#define EH_FRAME_OFFSETA MODE_CHOICE(176,0x90)
#define EH_FRAME_OFFSETB MODE_CHOICE(1,3)
+#define EH_FRAME_LABEL MODE_CHOICE(LEH_frame1,EH_frame1)
- .static_data
- .align LOG2_GPR_BYTES
-LLFB1$non_lazy_ptr:
- .g_long Lstartcode
-
.section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
-EH_frame1:
+EH_FRAME_LABEL:
.set L$set$0,LECIE1-LSCIE1
.long L$set$0 ; Length of Common Information Entry
LSCIE1:
@@ -484,7 +480,7 @@ LSCIE1:
.byte EH_DATA_ALIGN_FACT ; sleb128 -4; CIE Data Alignment Factor
.byte 0x41 ; CIE RA Column
.byte 0x1 ; uleb128 0x1; Augmentation size
- .byte 0x10 ; FDE Encoding (indirect pcrel)
+ .byte 0x10 ; FDE Encoding (pcrel)
.byte 0xc ; DW_CFA_def_cfa
.byte 0x1 ; uleb128 0x1
.byte 0x0 ; uleb128 0x0
@@ -497,8 +493,8 @@ LSFDE1:
.long L$set$1 ; FDE Length
LASFDE1:
- .long LASFDE1-EH_frame1 ; FDE CIE offset
- .g_long LLFB1$non_lazy_ptr-. ; FDE initial location
+ .long LASFDE1-EH_FRAME_LABEL ; FDE CIE offset
+ .g_long Lstartcode-. ; FDE initial location
.set L$set$3,LFE1-Lstartcode
.g_long L$set$3 ; FDE address range
.byte 0x0 ; uleb128 0x0; Augmentation size
Index: libffi/src/powerpc/darwin.S
===================================================================
--- libffi/src/powerpc/darwin.S (revision 185095)
+++ libffi/src/powerpc/darwin.S (working copy)
@@ -317,14 +317,10 @@ _ffi_call_AIX:
/* EH stuff. */
#define EH_DATA_ALIGN_FACT MODE_CHOICE(0x7c,0x78)
+#define EH_FRAME_LABEL MODE_CHOICE(LEH_frame1,EH_frame1)
- .static_data
- .align LOG2_GPR_BYTES
-LLFB0$non_lazy_ptr:
- .g_long Lstartcode
-
.section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
-EH_frame1:
+EH_FRAME_LABEL:
.set L$set$0,LECIE1-LSCIE1
.long L$set$0 ; Length of Common Information Entry
LSCIE1:
@@ -335,7 +331,7 @@ LSCIE1:
.byte EH_DATA_ALIGN_FACT ; sleb128 -4; CIE Data Alignment Factor
.byte 0x41 ; CIE RA Column
.byte 0x1 ; uleb128 0x1; Augmentation size
- .byte 0x10 ; FDE Encoding (indirect pcrel)
+ .byte 0x10 ; FDE Encoding (pcrel)
.byte 0xc ; DW_CFA_def_cfa
.byte 0x1 ; uleb128 0x1
.byte 0x0 ; uleb128 0x0
@@ -348,8 +344,8 @@ LSFDE1:
.set L$set$1,LEFDE1-LASFDE1
.long L$set$1 ; FDE Length
LASFDE1:
- .long LASFDE1-EH_frame1 ; FDE CIE offset
- .g_long LLFB0$non_lazy_ptr-. ; FDE initial location
+ .long LASFDE1-EH_FRAME_LABEL ; FDE CIE offset
+ .g_long Lstartcode-. ; FDE initial location
.set L$set$3,LFE1-Lstartcode
.g_long L$set$3 ; FDE address range
.byte 0x0 ; uleb128 0x0; Augmentation size
[-- Attachment #3: Type: text/plain, Size: 3 bytes --]
next parent reply other threads:[~2012-03-09 12:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4F53DC89.7000901@moxielogic.com>
2012-03-09 12:46 ` Iain Sandoe [this message]
2012-03-09 17:06 ` Mike Stump
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=32A48973-1E73-41B1-9037-AE857B097952@sandoe-acoustics.co.uk \
--to=developer@sandoe-acoustics.co.uk \
--cc=gcc-patches@gcc.gnu.org \
--cc=green@moxielogic.com \
--cc=libffi-discuss@sourceware.org \
--cc=mrs@gcc.gnu.org \
/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).