From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26679 invoked by alias); 27 Feb 2013 16:59:08 -0000 Received: (qmail 26671 invoked by uid 22791); 27 Feb 2013 16:59:07 -0000 X-SWARE-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 27 Feb 2013 16:58:57 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1UAkLI-00064J-6A from joseph_myers@mentor.com ; Wed, 27 Feb 2013 08:58:56 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Feb 2013 08:58:56 -0800 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Wed, 27 Feb 2013 16:58:54 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1UAkLF-0004A3-Fh; Wed, 27 Feb 2013 16:58:53 +0000 Date: Wed, 27 Feb 2013 16:59:00 -0000 From: "Joseph S. Myers" To: Richard Henderson CC: Subject: Re: [PATCH 00/26] ARM improvements In-Reply-To: <1361934986-17018-1-git-send-email-rth@twiddle.net> Message-ID: References: <1361934986-17018-1-git-send-email-rth@twiddle.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2013-02/txt/msg00102.txt.bz2 Could you please clarify how these patches have been tested? In particular, what testing has been done for big-endian (I think the string functions at least do need bit-endian testing - it should be possible to run string tests with userspace QEMU without needing BE hardware). > Patches 4-18 improve the ability to build libc as a thumb2 binary. > In the end, almost all assembly is done in thumb2 mode if -mthumb > is present in ASFLAGS. Its that last that's the sticky part: by > default we copy only a couple of flags over from CFLAGS. I'm not > sure why we're not passing them all to the assembler. So at the > moment I'm just putting ASFLAGS on the make command-line to get > what I want. I'd typically expect builds to be done with CC containing any relevant options for this sort of thing, rather than CFLAGS. That also raises the question of dependencies between the patches. Given a patch series like this, each subset 1-N of the patches should generally leave the tree in a working state. But if a patch (say patch 6) makes changes to .S code for __thumb2__ that are only correct after that actually means the generated code is Thumb-2 (patch 12) that leaves a broken intermediate state (given a compiler that defaults to Thumb-2, whether because configured --with-mode=thumb or because of the options in $CC), meaning the changes can't quite go in the given order (patch 5 could define pc_ofs unconditionally to 8 in assembly code, for example, and only patch 12 change the value for Thumb-2 assembly). -- Joseph S. Myers joseph@codesourcery.com