From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3088 invoked by alias); 12 Jun 2012 22:44:32 -0000 Received: (qmail 3079 invoked by uid 22791); 12 Jun 2012 22:44:30 -0000 X-SWARE-Spam-Status: No, hits=-0.3 required=5.0 tests=AWL,BAYES_00,KAM_STOCKTIP,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_DQ,TW_DR,TW_OV X-Spam-Check-By: sourceware.org Received: from mail-wg0-f51.google.com (HELO mail-wg0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Jun 2012 22:44:09 +0000 Received: by wgbed3 with SMTP id ed3so3886243wgb.8 for ; Tue, 12 Jun 2012 15:44:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=w7Bjht1+qAHk5gw3aNASdwBYzU0o/dbmeSBx6kxO8Gs=; b=gvA1fCwdnWOqZnj354HvfdHG8kNfHPx5TSWQz16Q498bQx04Du09BNL7T4uu2e9gPr Fg1vAFSxarFPfooWrIS0VL0Y5Ay8a2D8bOOG6xbmrwck4Prtn1Gua2ykqfti4rdZmqTB wGczSq4o5FyNYq5iwy6joeB1Cv6VQcN/xgs4H4Vf6dEjjem02DoH+rUOv4pXwJHMOJBx KKF5qkRhcIcNeU9bq9fiy9RKuNRR2UY8UDJMzksQss9umGYyCxakS8/JSMswdmML8cJb Ayls8PlxWrjVMas7oQGI/dXdFdpLpTaw8IlbwPMM7qMcsQsl+qUxAnqR9Qj+duiQ8w61 V/EA== Received: by 10.216.142.167 with SMTP id i39mr8986952wej.94.1339541047438; Tue, 12 Jun 2012 15:44:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.87.225 with HTTP; Tue, 12 Jun 2012 15:43:47 -0700 (PDT) In-Reply-To: <201206121432.q5CEWOlF019856@ignucius.se.axis.com> References: <201206102259.q5AMxvVH024138@ignucius.se.axis.com> <201206121432.q5CEWOlF019856@ignucius.se.axis.com> From: Michael Hope Date: Tue, 12 Jun 2012 23:15:00 -0000 Message-ID: Subject: Re: [RFA:] Caveat for ARM in gcc-4.7/changes.html: unaligned accesses To: Hans-Peter Nilsson Cc: gcc-patches@gcc.gnu.org, richard.earnshaw@arm.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnS3O1HYcnwJ6Coe+rEnsmelnxGLLcxvs27eflOJyHpFGIm+ci3O2Rr6z7bCAd2KOlOzCkx X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-06/txt/msg00771.txt.bz2 On 13 June 2012 02:32, Hans-Peter Nilsson wro= te: >> From: Hans-Peter Nilsson >> Date: Mon, 11 Jun 2012 00:59:57 +0200 > >> > From: Michael Hope >> > Date: Mon, 11 Jun 2012 00:04:19 +0200 >> >> > On 8 June 2012 16:53, Hans-Peter Nilsson = wrote: >> > >> From: Hans-Peter Nilsson >> > >> Date: Fri, 8 Jun 2012 06:29:04 +0200 >> > > >> > >> > From: Michael Hope >> > >> > Date: Fri, 8 Jun 2012 05:50:52 +0200 >> > >> > =A0The combination of >> > >> > older Linux ARM kernels and GCC 4.7 gives a faulty kernel. >> > >> >> > >> We're in agreement! >> > > >> > > Oh wait sorry, my bad, I misread. =A0Instead of "gives a faulty >> > > kernel", I'd say "for ARMv6 and later (not -M), gives faulty >> > > user-space code". =A0Maybe the kernel too, I can't say; there was >> > > IIRC no sign of it. > > But (at least) after removing some local changed defaults, > there's at boot-time a lot of: > > [ =A0 =A00.950000] Unhandled fault: alignment exception (0x801) at 0xc821= ddee That's a kernel address. What does /proc/kallsyms say is there? For reference, the message comes from arch/arm/mm/alignment.c:alignment_init() from the default trap handler. The lines just before this disable the unaligned trap for usermode: if (cpu_is_v6_unaligned()) { cr_alignment &=3D ~CR_A; cr_no_alignment &=3D ~CR_A; set_cr(cr_alignment); ai_usermode =3D safe_usermode(ai_usermode, false); } Support was added by Russell King in 2008-12 and updated by Dave Martin on 2011-07. Out of interest, does your CPU report support for unaligned access via CP15 CR1? It's bit 22 and shows during boot. My board shows: CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=3D50c5387d >> > Is there a bugzilla ticket logged for this? =A0I'd like to try to repr= oduce it. > > Here's a shorter case I'll attach to a PR for this unless it > gets resolved one way or another soonish. =A0Remember, you'll have > to run this on a pre-3.2 kernel with CONFIG_ALIGNMENT_TRAP on > (the default) and you have to compile for ARM v6 or later (as in > -march=3Darmv6). =A0Using gcc-4.7.1-rc1 should do, most likely > earlier revisions too. > > __attribute__ ((__noinline__, __noclone__)) > void doit(char *x) > { > =A0asm (""); > =A0__builtin_strcpy (x, "stat"); > } > > int main(void) > { > =A0char x[30]; > =A0doit(x + 1); > =A0doit(x); > =A0__builtin_exit (0); > } This compiles into a five byte unaligned memcpy: doit: mov r2, r0 movw r3, #:lower16:.LC0 movt r3, #:upper16:.LC0 ldr r0, [r3, #0] @ unaligned ldrb r3, [r3, #4] @ zero_extendqisi2 str r0, [r2, #0] @ unaligned strb r3, [r2, #4] bx lr which is correct. The test case runs on my boards and kernels as noted below. /proc/cpu/alignment doesn't change so the loads and stores were handled by the hardware. I added: __attribute__ ((__noinline__, __noclone__)) long long doit2(char *x) { asm (""); return *(long long *)x; } which becomes: doit2: ldmia r0, {r0, r1} bx lr ldm must be aligned. The program runs to completion but this time the kernel traps and handles the unaligned load: cbuild@ursa1:~/bugs$ cat /proc/cpu/alignment > before cbuild@ursa1:~/bugs$ ./a.out cbuild@ursa1:~/bugs$ cat /proc/cpu/alignment > after cbuild@ursa1:~/bugs$ diff -u before after --- before 2012-06-12 22:29:20.428268001 +0000 +++ after 2012-06-12 22:29:26.107955560 +0000 @@ -1,8 +1,8 @@ -User: 3 +User: 4 System: 7 Skipped: 0 Half: 0 Word: 0 DWord: 0 -Multi: 10 +Multi: 11 User faults: 2 (fixup) >> > It's interesting as we backported the patch into the Linaro GCC that >> > was used to build Ubuntu Precise and didn't find any faults. > > I have no idea why you didn't run into this, unless it was one > of the obvious reasons: not building for ARM v6 or the kernel > was 3.2 or later, or configured with CONFIG_ALIGNMENT_TRAP off. > Or other local patches of yours. Linaro's stock configuration is -march=3Darmv7-a -mtune=3Dcortex-a9 -mthumb. Ubuntu is the same. I can't reproduce the fault on a PandaBoard with omapzoom 2.6.35, Ubuntu 3.2.14, Ubuntu Precise 4.6.3 GCC, or plain gcc-4.7.1-RC-20120606. The configurations for the kernels are at: * http://bazaar.launchpad.net/~linaro-toolchain-dev/cbuild/hardware/view/h= ead:/ursa/r2/config * http://bazaar.launchpad.net/~linaro-toolchain-dev/cbuild/hardware/view/h= ead:/distro/precise/r1/config and have CONFIG_ALIGNMENT_TRAP on. -- Michael