linaro-toolchain December 2012

linaro-toolchain@lists.linaro.org

20 participants
47 discussions

Re: [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores

by Michael Hope

On 6 November 2012 02:48, Rob Herring <robherring2(a)gmail.com> wrote: > > On 11/05/2012 05:13 AM, Russell King - ARM Linux wrote: > > On Mon, Nov 05, 2012 at 10:48:50AM +0000, Dave Martin wrote: > >> On Thu, Oct 25, 2012 at 05:08:16PM +0200, Johannes Stezenbach wrote: > >>> On Thu, Oct 25, 2012 at 09:25:06AM -0500, Rob Herring wrote: > >>>> On 10/25/2012 09:16 AM, Johannes Stezenbach wrote: > >>>>> On Thu, Oct 25, 2012 at 07:41:45AM -0500, Rob Herring wrote: > >>>>>> On 10/25/2012 04:34 AM, Johannes Stezenbach wrote: > >>>>>>> On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote: > >>>>>>> > >>>>>>>> While v6 can support unaligned accesses, it is optional and current > >>>>>>>> compilers won't emit unaligned accesses. So we don't clear the A bit for > >>>>>>>> v6. > >>>>>>> > >>>>>>> not true according to the gcc changes page > >>>>>> > >>>>>> What are you going to believe: documentation or what the compiler > >>>>>> emitted? At least for ubuntu/linaro 4.6.3 which has the unaligned access > >>>>>> support backported and 4.7.2, unaligned accesses are emitted for v7 > >>>>>> only. I guess default here means it is the default unless you change the > >>>>>> default in your build of gcc. > >>>>> > >>>>> Since ARMv6 can handle unaligned access in the same way as ARMv7 > >>>>> it seems a clear bug in gcc which might hopefully get fixed. > >>>>> Thus in this case I think it is reasonable to follow the > >>>>> gcc documentation, otherwise the code would break for ARMv6 > >>>>> when gcc gets fixed. > >>>> > >>>> But the compiler can't assume the state of the U bit. I think it is > >>>> still legal on v6 to not support unaligned accesses, but on v7 it is > >>>> required. All the standard v6 ARM cores support it, but I'm not sure > >>>> about custom cores or if there are SOCs with buses that don't support > >>>> unaligned accesses properly. > >>> > >>> Well, I read the "...since Linux version 2.6.28" comment > >>> in the gcc changes page in the way that they assume the > >>> U-bit is set. (Although I'm not sure it really is???) > >> > >> Actually, the kernel checks the arch version and the U bit on boot, > >> and chooses the appropriate setting for the A bit depending on the > >> result. (See arch/arm/mm/alignment.c:alignment_init().) > > > > That is in the kernel itself, _after_ the decompressor has run. It is > > not relevant to any discussion about the decompressor. > > > >> Currently, we depend on the CPU reset behaviour or firmware/ > >> bootloader to set the U bit for v6, but the behaviour should be > >> correct either way, though unaligned accesses will obviously > >> perform (much) better with U=1. > > > > Will someone _PLEASE_ address my initial comments against this patch > > in light of the fact that it's now been proven _NOT_ to be just a V7 > > issue, rather than everyone seemingly buring their heads in the sand > > over this. > > I tried adding -munaligned-accesses on a v6 build and still get byte > accesses rather than unaligned word accesses. So this does seem to be a > v7 only issue based on what gcc will currently produce. Copying Michael > Hope who can hopefully provide some insight on why v6 unaligned accesses > are not enabled. This looks like a bug. Unaligned access is enabled for armv6 but seems to only take effect for cores with Thumb-2. Here's a test case both with unaligned field access and unaligned block copy: struct foo { char a; int b; struct { int x[3]; } c; } __attribute__((packed)); int get_field(struct foo *p) { return p->b; } int copy_block(struct foo *p, struct foo *q) { p->c = q->c; } With -march=armv7-a you get the correct: bar: ldr r0, [r0, #1] @ unaligned @ 11 unaligned_loadsi/2 [length = 4] bx lr @ 21 *arm_return [length = 12] baz: str r4, [sp, #-4]! @ 25 *push_multi [length = 4] mov r2, r0 @ 2 *arm_movsi_vfp/1 [length = 4] ldr r4, [r1, #5]! @ unaligned @ 9 unaligned_loadsi/2 [length = 4] ldr ip, [r1, #4] @ unaligned @ 10 unaligned_loadsi/2 [length = 4] ldr r1, [r1, #8] @ unaligned @ 11 unaligned_loadsi/2 [length = 4] str r4, [r2, #5] @ unaligned @ 12 unaligned_storesi/2 [length = 4] str ip, [r2, #9] @ unaligned @ 13 unaligned_storesi/2 [length = 4] str r1, [r2, #13] @ unaligned @ 14 unaligned_storesi/2 [length = 4] ldmfd sp!, {r4} bx lr With -march=armv6 you get a byte-by-byte field access and a correct unaligned block copy: bar: ldrb r1, [r0, #2] @ zero_extendqisi2 ldrb r3, [r0, #1] @ zero_extendqisi2 ldrb r2, [r0, #3] @ zero_extendqisi2 ldrb r0, [r0, #4] @ zero_extendqisi2 orr r3, r3, r1, asl #8 orr r3, r3, r2, asl #16 orr r0, r3, r0, asl #24 bx lr baz: str r4, [sp, #-4]! mov r2, r0 ldr r4, [r1, #5]! @ unaligned ldr ip, [r1, #4] @ unaligned ldr r1, [r1, #8] @ unaligned str r4, [r2, #5] @ unaligned str ip, [r2, #9] @ unaligned str r1, [r2, #13] @ unaligned ldmfd sp!, {r4} bx lr readelf -A shows that the compiler planned to use unaligned access in both. My suspicion is that GCC is using the extv pattern to extract the field from memory, and that pattern is only enabled for Thumb-2 capable cores. I've logged PR55218. We'll discuss it at our next meeting. -- Michael

11 years, 9 months

R_ARM_TLS_DTPMOD32 Relocation

by naveen yadav

Dear All, When doing prelink I got following error. /a.out /a.out: R_ARM_TLS_DTPMOD32 reloc in executable? Gcc version 4.6 I have following question: 1. What this relocation do. ? 2. Is it problem in tool chain ? 3. Are we need to fix this in Prelink utils Thanks

11 years, 10 months

int64_t definition conflict on Aarch64

by Riku Voipio

Hi, The following code fails to build with OE Aarch64 toolchain with current kernel headers. While ugly, the code is a reduced testcase from fuse build failure ( https://bugs.launchpad.net/linaro-oe/+bug/1087757 ) and the same fuse code compiles on all other architectures. Before I send a workaround for upstream, I'd like to know how we can end up with different definitions for int64_t when that happens on no other architectures - something wrong with the generic kernel headers? Testcase: #include <sys/types.h> #define __s64 int64_t #include <signal.h> int main(int argc, char **argv) { int64_t x=4; return x; } Failure: /data/oe/build/tmp-eglibc/sysroots/x86_64-linux/usr/bin/aarch64-oe-linux/aarch64-oe-linux-gcc -save-temps --sysroot=/data/oe/build/tmp-eglibc/sysroots/genericarmv8 -o test test.c In file included from /data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/asm-generic/types.h:7:0, from /data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/asm/types.h:1, from /data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/linux/types.h:4, from /data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/asm/sigcontext.h:19, from /data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/bits/sigcontext.h:27, from /data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/signal.h:338, from test.c:4: /data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/asm-generic/int-ll64.h:29:44: error: conflicting types for 'int64_t' In file included from test.c:2:0: /data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/sys/types.h:197:13: note: previous declaration of 'int64_t' was here

11 years, 10 months

[Activity] Week 52

by Zhenqiang Chen

Summary: * Follow-up shrink-up and branch cost related work. * Investigate "MSR FPEXC, r2" assemble fail issues. Details: 1. RM toolchain related work. 2. Investigate "MSR FPEXC, r2" assemble fail issues. * According to Reference Manual, should use VMSR/VMRS to access FPEXC register other than MSR/MRS. * Binutils 2.23.1 or later had enhanced VMRS/VMSR to accept FPEXC register. 3. Rebase and test the shrink-wrap patches. 4. Read codes about impact of branch-cost. Plan: * Follow up the shrink-wrap and branch cost related work. Planed leaves: * Jan. 1-3, 2013 Best Regards! -Zhenqiang

11 years, 11 months

Cant't read arm-linux-gnueabihf-ct-ng.config

by ljc

Hi all! I'm rebuildding linaro-toolchain with ct-ng,I expect use the configure file in linaro-toolchain-binaries ,but I can't read the options in it's arm-linux-gnueabihf-ct-ng.config. How I can do? Thanks!

11 years, 11 months

[ACTIVITY] 17-21 December 2012

by Christophe Lyon

== Progress == * 64-bits ops in Neon: re-posted patch after a bit of cleanup requested by upstream. Investigated Fortran regression: confirmed unrelated to this patched, and fixed upstream. * disable-peeling: launched jobs under cbuild to perform initial benchmarking * builtin_bswap16 backport to linaro-4.7: almost OK, missing some pending validation results. * cbuild: investigated some reporting problems which were slowing down the branch review process. == Next == * handle 64-bits bitops in Neon feedback from upstream if any * finish builtin_bswap16 backport * benchmark with vectorizer cost model enabled with its default configuration == Future == Back on January 7th, after the end of the world.

11 years, 11 months

[ACTIVITY] 17-21 December 2012

by Matthew Gretton-Dann

== Blueprints == Initial Current Actual initial-aarch64-backport 31 Oct 2012 31 Dec 2012 21 Dec 2012 aarch64-baremetal-testing 31 Oct 2012 31 Dec 2012 21 Dec 2012 backport-fma-intrinsic 31 Dec 2012 Brice fused-multiply-add-support 31 Dec 2012 Brice gcc-investigate-lra-for-arm 31 Dec 2012 Brice fix-gcc-multiarch-testing 31 Dec 2012 31 Jan 2013 == Progress == * Admin * Interviewing * Welcomed Brice Dobry to the working group * Started inputting cards into cards.linaro.org * Discussions about KVM * Discussions about Toolchain/Platform interactions * initial-aarch64-backport and aarch64-baremetal-testing * Finished documentation == Next (working) week == * Admin * Finish loading card drafts into Jira. * Welcome Renato to working group. * Do monthly GCC merges * Prepare Cortex Strings release * Ensure GCC backports are up to date. == Future == * Run HOT/COLD partitioning benchmarks * Analyse ARM results * On x86_64 to see what the actual benefit we could get * fix-gcc-multiarch-testing * Come up with strawman proposal for updating testsuite to handle testing with varying command-line options. -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-dann(a)linaro.org

11 years, 11 months

Re: [Merge] lp:~brice-dobry/gcc-linaro/fma into lp:gcc-linaro

by Matthew Gretton-Dann

On 21 December 2012 09:54, Yvan Roux <yvan.roux(a)linaro.org> wrote: > Matt, do you have something particular in mind to put in a shared and versioned .bzrignore file ? > My understanding of its usage is that it is more a user side configuration of the archive. > (Maybe we could chat about this topic on another channel) Yes this conversation should probably be conducted elsewhere :-) - moved to linaro-toolchain. If you look at upstream SVN GCC and do svn propget svn:ignore you get a long list of files that SVN is set up to ignore. And whilst there isn't a .gitignore other upstream projects which have git mirrors do put a .gitignore in place (see GDB for instance). I think having a .bzrignore which is a copy of the svn:ignore set up (and the defaults that SVN ignores but aren't on bzr's list) would be valid in the repo. Although as I said in the original thread - let's do this when we branch 4.8 and not to the historic branches. Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-dann(a)linaro.org

11 years, 11 months

[ANNOUNCE] Linaro Toolchain Binaries 2012.12 released

by Zhenqiang Chen

The Linaro Toolchain Working Group is pleased to announce the 2012.12 release of the Linaro Toolchain Binaries, a pre-built version of Linaro GCC and Linaro GDB that runs on generic Linux or Windows and targets the glibc Linaro Evaluation Build. Uses include: * Cross compiling ARM applications from your laptop * Remote debugging * Build the Linux kernel for your board What's included: * Linaro GCC 4.7 2012.12 * Linaro GDB 7.5 2012.12 * A statically linked gdbserver * A system root * Manuals under share/doc/ The system root contains the basic header files and libraries to link your programs against. The Linux version is supported on Ubuntu 10.04.3 and 12.04, Debian 6.0.2, Fedora 16, openSUSE 12.1, Red Hat Enterprise Linux Workstation 5.7 and later, and should run on any Linux Standard Base 3.0 compatible distribution. Please see the README about running on x86_64 hosts. The Windows version is supported on Windows XP Pro SP3, Windows Vista Business SP2, and Windows 7 Pro SP1. The binaries and build scripts are available from: https://launchpad.net/linaro-toolchain-binaries/trunk/2012.12 Need help? Ask a question on https://ask.linaro.org/ Already on Launchpad? Submit a bug at https://bugs.launchpad.net/linaro-toolchain-binaries On IRC? See us on #linaro on Freenode. Other ways that you can contact us or get involved are listed at https://wiki.linaro.org/GettingInvolved.

11 years, 11 months

[ACTIVITY] 10 - 14 December 2012

by Yvan Roux

== Progress == * Release week: - Made 2012.12 release of gcc-linaro 4.6 and 4.7. - took lot of time (infrastructure, right acess, Lava lab migration) * GCC atomic builtins: - my load acquire patch was applied up-stream (trunk and 4.7). - some cleaning in optabs.c (patch applied up-stream too). == Next == * Resume Boehm GC AArch64 support. * Review roster.

11 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain December 2012