Re: Questions about the libffi development process

[Russell Keith-Magee <russell@keith-magee.com>]

Hi Richard,

On Fri, Apr 24, 2015 at 3:13 AM, Richard Henderson <rth@redhat.com> wrote:
> 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 can't argue with that. Deleting the port would certainly be an
option. It obviously wouldn't be my *preferred* option, but it's
obviously *an* option.

That said, I don't think it's fair to call their contributions
"dumped" or "unmaintained". I can't speak for the person who
originally submitted the iOS port, but iOS support on ARMv7 has been
working fine for several years. It has received 100% of the
maintenance it has required. Prior to this recent refactor, the last
changes to sysv.S were in Feb 2014, Dec 2013, and April 2012. On that
basis, I don't think it's out of the realm of possibility that the
original contributors aren't actively watching trunk libffi
development. They may not even be aware that this change has landed.
To cast blame on them for not being immediately aware that someone
else has merged a patch that massively refactors (and inadvertently
breaks) code that was working fine is a little unfair to everyone
involved.

Is there a good record of who is notionally "responsible" for iOS
support? Based on the git logs, Zachary Waldowski and David Schneider
would seem to be the most likely candidates.

>> 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.

None at all? There's no release candidate process? No release testing
procedures?

>> 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.

It certainly cleans up a lot of the compilation problems. Updated log follows:

===

libtool: compile:  xcrun -sdk iphoneos clang -arch armv7
-DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -I.
-I../include -Iinclude -I../src -miphoneos-version-min=7.0 -MT
src/arm/sysv.lo -MD -MP -MF src/arm/.deps/sysv.Tpo -c
../src/arm/sysv.S  -fno-common -DPIC -o src/arm/.libs/sysv.o
../src/arm/sysv.S:111:2: error: .arch directive not valid for Mach-O
 .arch armv5t
 ^
../src/arm/sysv.S:128:8: error: invalid operand for instruction
 ldcle p11, cr0, [r0] @ vldrle d0, [sp]
       ^
../src/arm/sysv.S:129:8: error: invalid operand for instruction
 ldcgt p11, cr0, [r0], {16} @ vldmgt sp, {d0-d7}
       ^
../src/arm/sysv.S:167:6: error: invalid operand for instruction
 stc p10, cr0, [r2] @ vstr s0, [r2]
     ^
../src/arm/sysv.S:170:6: error: invalid operand for instruction
 stc p11, cr0, [r2] @ vstr d0, [r2]
     ^
../src/arm/sysv.S:173:6: error: invalid operand for instruction
 stc p11, cr0, [r2], {8} @ vstm r2, {d0-d3}
     ^
../src/arm/sysv.S:262:6: error: invalid operand for instruction
 stc p11, cr0, [sp], {16} @ vstm sp, {d0-d7}
     ^
../src/arm/sysv.S:291:6: error: invalid operand for instruction
 ldc p10, cr0, [r2] @ vldr s0, [r2]
     ^
../src/arm/sysv.S:294:6: error: invalid operand for instruction
 ldc p11, cr0, [r2] @ vldr d0, [r2]
     ^
../src/arm/sysv.S:297:6: error: invalid operand for instruction
 ldc p11, cr0, [r2], {8} @ vldm r2, {d0-d3}
     ^
===

To my untrained eye, this looks like there is only 2 underlying problems:
 * .arch being an invalid directive.
 * p10 and p11 being invalid operands for ldcle, ldcgt, ldc and stc

Again, I can't thank you enough for taking a look at this problem,
even though it's outside your bailiwick.

Yours,
Russ Magee %-)