From: Richard Henderson <rth@redhat.com>
To: Russell Keith-Magee <russell@keith-magee.com>
Cc: libffi-discuss@sourceware.org
Subject: Re: Questions about the libffi development process
Date: Thu, 23 Apr 2015 19:13:00 -0000 [thread overview]
Message-ID: <55394442.9020701@redhat.com> (raw)
In-Reply-To: <CAJxq84-=Acm-aWSqTZ5+vyPbm2K3bwYbwPnRXvAAj7UEcuhjMA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]
On 04/22/2015 10:25 PM, Russell Keith-Magee wrote:
> I can certainly appreciate the problem of having access to appropriate
> hardware for testing, and I'm definitely appreciative of the efforts
> of those (such as yourself) who are doing work that I don't have the
> skills to handle myself. If nothing else, the patch that caused this
> ARMv7 problem also *fixed* a big problem on iOS AARCH64; for that, you
> definitely have my gratitude.
>
> My concern is that it isn't at all clear how the project as a whole is
> responding to this problem - hence my original question. From the
> perspective of an outside observer - someone who *uses* libffi, and
> can definitely report bugs, but isn't in a good position to fix bugs -
> a patch has been applied to trunk that fails the most basic of
> acceptance tests.
I reject that characterization.
The breakdown I see is that whoever submitted the iOS port in the first place
just dumped the code and left. They are failing to maintain their port. In
other projects, that is grounds for simply deleting the port entirely. On the
basis that users can either maintain the port, or continue using the last
version that did work. To do otherwise holds the entire project hostage to a
port that no one can (or cares to) maintain.
> I'm asking what, if any,
> processes are in place to make sure that a known critical bug doesn't
> get rolled into a stable release; and what, if any, processes are in
> place to get this bug in front of the eyes of people who *are* in a
> position to fix it.
None.
> That solution (or something close to it) was already proposed on
> ticket #181; while it does solve one compilation problem, it opens a
> whole lot more errors. Compile log follows:
Ok. Guessing, based on other changes I've made for clang on other ports, the
following has a chance of working. Sadly, fedora 21 clang is totally
mis-configured so I can't easily test that on arm-linux.
r~
[-- Attachment #2: d-arm-clang --]
[-- Type: text/plain, Size: 5849 bytes --]
diff --git a/src/arm/sysv.S b/src/arm/sysv.S
index fd16589..db70a7d 100644
--- a/src/arm/sysv.S
+++ b/src/arm/sysv.S
@@ -52,11 +52,12 @@
#endif
/* Conditionally compile unwinder directives. */
-.macro UNWIND text:vararg
#ifdef __ARM_EABI__
- \text
+# define UNWIND(...) __VA_ARGS__
+#else
+# define UNWIND(...)
#endif
-.endm
+
#if defined(HAVE_AS_CFI_PSEUDO_OP) && defined(__ARM_EABI__)
.cfi_sections .debug_frame
#endif
@@ -77,21 +78,29 @@
# define TYPE(X, Y)
#endif
-#define ARM_FUNC_START(name, gl) \
- .align 3; \
- .ifne gl; .globl CNAME(name); FFI_HIDDEN(CNAME(name)); .endif; \
- TYPE(name, %function); \
+#define ARM_FUNC_START_LOCAL(name) \
+ .align 3; \
+ TYPE(CNAME(name), %function); \
CNAME(name):
+#define ARM_FUNC_START(name) \
+ .globl CNAME(name); \
+ FFI_HIDDEN(CNAME(name)); \
+ ARM_FUNC_START_LOCAL(name)
+
#define ARM_FUNC_END(name) \
SIZE(name)
/* Aid in defining a jump table with 8 bytes between entries. */
-.macro E index
- .if . - 0b - 8*\index
- .error "type table out of sync"
+/* ??? The clang assembler doesn't handle .if with symbolic expressions. */
+#ifdef __clang__
+# define E(index)
+#else
+# define E(index) \
+ .if . - 0b - 8*index; \
+ .error "type table out of sync"; \
.endif
-.endm
+#endif
.text
.syntax unified
@@ -111,8 +120,8 @@
@ r2: fn
@ r3: vfp_used
-ARM_FUNC_START(ffi_call_VFP, 1)
- UNWIND .fnstart
+ARM_FUNC_START(ffi_call_VFP)
+ UNWIND(.fnstart)
cfi_startproc
cmp r3, #3 @ load only d0 if possible
@@ -122,14 +131,14 @@ ARM_FUNC_START(ffi_call_VFP, 1)
/* FALLTHRU */
ARM_FUNC_END(ffi_call_VFP)
-ARM_FUNC_START(ffi_call_SYSV, 1)
+ARM_FUNC_START(ffi_call_SYSV)
stm r1, {fp, lr}
mov fp, r1
@ This is a bit of a lie wrt the origin of the unwind info, but
@ now we've got the usual frame pointer and two saved registers.
- UNWIND .save {fp,lr}
- UNWIND .setfp fp, sp
+ UNWIND(.save {fp,lr})
+ UNWIND(.setfp fp, sp)
cfi_def_cfa(fp, 8)
cfi_rel_offset(fp, 0)
cfi_rel_offset(lr, 4)
@@ -154,29 +163,29 @@ ARM_FUNC_START(ffi_call_SYSV, 1)
add pc, pc, r3, lsl #3
nop
0:
-E ARM_TYPE_VFP_S
+E(ARM_TYPE_VFP_S)
stc p10, cr0, [r2] @ vstr s0, [r2]
pop {fp,pc}
-E ARM_TYPE_VFP_D
+E(ARM_TYPE_VFP_D)
stc p11, cr0, [r2] @ vstr d0, [r2]
pop {fp,pc}
-E ARM_TYPE_VFP_N
+E(ARM_TYPE_VFP_N)
stc p11, cr0, [r2], {8} @ vstm r2, {d0-d3}
pop {fp,pc}
-E ARM_TYPE_INT64
+E(ARM_TYPE_INT64)
str r1, [r2, #4]
nop
-E ARM_TYPE_INT
+E(ARM_TYPE_INT)
str r0, [r2]
pop {fp,pc}
-E ARM_TYPE_VOID
+E(ARM_TYPE_VOID)
pop {fp,pc}
nop
-E ARM_TYPE_STRUCT
+E(ARM_TYPE_STRUCT)
pop {fp,pc}
cfi_endproc
- UNWIND .fnend
+ UNWIND(.fnend)
ARM_FUNC_END(ffi_call_SYSV)
@@ -184,7 +193,7 @@ ARM_FUNC_END(ffi_call_SYSV)
int ffi_closure_inner_* (cif, fun, user_data, frame)
*/
-ARM_FUNC_START(ffi_go_closure_SYSV, 1)
+ARM_FUNC_START(ffi_go_closure_SYSV)
cfi_startproc
stmdb sp!, {r0-r3} @ save argument regs
cfi_adjust_cfa_offset(16)
@@ -195,8 +204,8 @@ ARM_FUNC_START(ffi_go_closure_SYSV, 1)
cfi_endproc
ARM_FUNC_END(ffi_go_closure_SYSV)
-ARM_FUNC_START(ffi_closure_SYSV, 1)
- UNWIND .fnstart
+ARM_FUNC_START(ffi_closure_SYSV)
+ UNWIND(.fnstart)
cfi_startproc
stmdb sp!, {r0-r3} @ save argument regs
cfi_adjust_cfa_offset(16)
@@ -212,7 +221,7 @@ ARM_FUNC_START(ffi_closure_SYSV, 1)
/* Remember that EABI unwind info only applies at call sites.
We need do nothing except note the save of the stack pointer
and the link registers. */
- UNWIND .save {sp,lr}
+ UNWIND(.save {sp,lr})
cfi_adjust_cfa_offset(8)
cfi_rel_offset(lr, 4)
@@ -224,10 +233,10 @@ ARM_FUNC_START(ffi_closure_SYSV, 1)
adr r3, CNAME(ffi_closure_ret)
add pc, r3, r0, lsl #3
cfi_endproc
- UNWIND .fnend
+ UNWIND(.fnend)
ARM_FUNC_END(ffi_closure_SYSV)
-ARM_FUNC_START(ffi_go_closure_VFP, 1)
+ARM_FUNC_START(ffi_go_closure_VFP)
cfi_startproc
stmdb sp!, {r0-r3} @ save argument regs
cfi_adjust_cfa_offset(16)
@@ -238,8 +247,8 @@ ARM_FUNC_START(ffi_go_closure_VFP, 1)
cfi_endproc
ARM_FUNC_END(ffi_go_closure_VFP)
-ARM_FUNC_START(ffi_closure_VFP, 1)
- UNWIND .fnstart
+ARM_FUNC_START(ffi_closure_VFP)
+ UNWIND(.fnstart)
cfi_startproc
stmdb sp!, {r0-r3} @ save argument regs
cfi_adjust_cfa_offset(16)
@@ -254,7 +263,7 @@ ARM_FUNC_START(ffi_closure_VFP, 1)
stmdb sp!, {ip,lr}
/* See above. */
- UNWIND .save {sp,lr}
+ UNWIND(.save {sp,lr})
cfi_adjust_cfa_offset(8)
cfi_rel_offset(lr, 4)
@@ -266,37 +275,37 @@ ARM_FUNC_START(ffi_closure_VFP, 1)
adr r3, CNAME(ffi_closure_ret)
add pc, r3, r0, lsl #3
cfi_endproc
- UNWIND .fnend
+ UNWIND(.fnend)
ARM_FUNC_END(ffi_closure_VFP)
/* Load values returned in registers for both closure entry points.
Note that we use LDM with SP in the register set. This is deprecated
by ARM, but not yet unpredictable. */
-ARM_FUNC_START(ffi_closure_ret, 0)
+ARM_FUNC_START_LOCAL(ffi_closure_ret)
cfi_startproc
cfi_rel_offset(sp, 0)
cfi_rel_offset(lr, 4)
0:
-E ARM_TYPE_VFP_S
+E(ARM_TYPE_VFP_S)
ldc p10, cr0, [r2] @ vldr s0, [r2]
ldm sp, {sp,pc}
-E ARM_TYPE_VFP_D
+E(ARM_TYPE_VFP_D)
ldc p11, cr0, [r2] @ vldr d0, [r2]
ldm sp, {sp,pc}
-E ARM_TYPE_VFP_N
+E(ARM_TYPE_VFP_N)
ldc p11, cr0, [r2], {8} @ vldm r2, {d0-d3}
ldm sp, {sp,pc}
-E ARM_TYPE_INT64
+E(ARM_TYPE_INT64)
ldr r1, [r2, #4]
nop
-E ARM_TYPE_INT
+E(ARM_TYPE_INT)
ldr r0, [r2]
ldm sp, {sp,pc}
-E ARM_TYPE_VOID
+E(ARM_TYPE_VOID)
ldm sp, {sp,pc}
nop
-E ARM_TYPE_STRUCT
+E(ARM_TYPE_STRUCT)
ldm sp, {sp,pc}
cfi_endproc
ARM_FUNC_END(ffi_closure_ret)
@@ -319,10 +328,11 @@ ARM_FUNC_START(ffi_closure_trampoline_table_page)
ldr ip, [pc, #-4092]
ldr pc, [pc, #-4092]
.endr
+ARM_FUNC_END(ffi_closure_trampoline_table_page)
#else
-ARM_FUNC_START(ffi_arm_trampoline, 1)
+ARM_FUNC_START(ffi_arm_trampoline)
0: adr ip, 0b
ldr pc, 1f
1: .long 0
next prev parent reply other threads:[~2015-04-23 19:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-18 6:29 Russell Keith-Magee
2015-04-21 18:11 ` Richard Henderson
2015-04-23 8:25 ` Russell Keith-Magee
2015-04-23 19:13 ` Richard Henderson [this message]
2015-04-24 1:49 ` Russell Keith-Magee
2015-04-24 16:29 ` Richard Henderson
2015-04-25 11:15 ` Russell Keith-Magee
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=55394442.9020701@redhat.com \
--to=rth@redhat.com \
--cc=libffi-discuss@sourceware.org \
--cc=russell@keith-magee.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).