From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84595 invoked by alias); 24 Apr 2015 01:49:19 -0000 Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org Received: (qmail 84466 invoked by uid 89); 24 Apr 2015 01:49:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wi0-f169.google.com Received: from mail-wi0-f169.google.com (HELO mail-wi0-f169.google.com) (209.85.212.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 24 Apr 2015 01:49:16 +0000 Received: by widdi4 with SMTP id di4so4831151wid.0 for ; Thu, 23 Apr 2015 18:49:13 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.181.11.227 with SMTP id el3mr1985536wid.87.1429840153622; Thu, 23 Apr 2015 18:49:13 -0700 (PDT) Received: by 10.194.29.65 with HTTP; Thu, 23 Apr 2015 18:49:13 -0700 (PDT) In-Reply-To: <55394442.9020701@redhat.com> References: <553692BE.2070306@redhat.com> <55394442.9020701@redhat.com> Date: Fri, 24 Apr 2015 01:49:00 -0000 Message-ID: Subject: Re: Questions about the libffi development process From: Russell Keith-Magee To: Richard Henderson Cc: libffi-discuss@sourceware.org Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015/txt/msg00058.txt.bz2 Hi Richard, On Fri, Apr 24, 2015 at 3:13 AM, Richard Henderson 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 %-)