- linaro-toolchain - lists.linaro.org

Re: Re: Re: unexpected reloc type 0x03 error with gcc-4.6.4 (2012.10 version)

by 남관우

13 years, 6 months

1
0
0 0

Re: Compilation speed of Linaro's gcc compared to e.g. Ubuntu's version

by Michael Hope

On 10 November 2012 05:11, "Frank Müller" <franky1976(a)gmx.net> wrote: > Michael Hope <michael.hope(a)linaro.org>: >> My suspicion is that we/crosstool-NG enable extra features like >> Graphite or GCC is built with a different level of checking. If you > > I suspected Graphite as well and removed it in my own builds without noticable difference. > >> have the time, could you check the flags passed to GCCs configure? >> You can do this on Ubuntu using: >> >> apt-get build-dep gcc >> apt-get source gcc >> dpkg-buildpackage -uc -us -b >> >> and compare the configure line with the one in crosstool-NG's build.log. > > Isn't this the same as gcc -v? I've posted the lines at http://lists.linaro.org/pipermail/linaro-toolchain/2012-October/002913.html Good point. There's nothing obvious in the list. Ubuntu explicitly adds --enable-checking=release but it's the default for release branches like ours. I can reproduce the slowdown in a smaller testcase. Compiling pcre with -O3 -mfpu=neon -march=armv7-a -mtune=cortex-a8 takes 18.8 s for the Ubuntu Precise 4.6 compiler, 17.8 s for the Ubuntu Quantal 4.7 compiler, and 41.2 s for the Linaro 4.7 2012.10 build. I've logged LP: #1077739 to track. I'll spin a --enable-checking=release build just to check. > The above lines do not work for me, the last line misses a changelog file: > > # dpkg-buildpackage -uc -us -b > tail: cannot open `debian/changelog' for reading: No such file or directory > dpkg-buildpackage: error: tail of debian/changelog gave error exit status 1 Yip, you need to change to the just-extracted source directory first. -- Michael

13 years, 6 months

4
5
0 0

Re: Re: unexpected reloc type 0x03 error with gcc-4.6.4 (2012.10 version)

by Michael Hope

On 14 November 2012 00:48, 남관우 <kw46.nam(a)samsung.com> wrote: > > Hi, > > > > First, our CFLAGS is here. > > > > -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Wl,--as-needed > -fmessage-length=0 -march=armv7-a -mtune=cortex-a8 -mfpu=vfpv3-d16 -mfloat-abi=hard -mthumb -Wa,-mimplicit-it=thumb > -mapcs -mno-sched-prolog -mabi=aapcs-linux -Uarm -fno-common -fpic > > > > It was occurred with the message. (/usr/lib/libnfc-common-lib.so.1: unexpected reloc type 0x03) > > > > Second, > > -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Wl,--as-needed > -fmessage-length=0 -march=armv7-a -mtune=cortex-a8 -mfpu=vfpv3-d16 -mfloat-abi=hard -mthumb -Wa,-mimplicit-it=thumb > -mapcs -mno-sched-prolog -fno-common -fpic > > > > It was occurred too. (/usr/lib/libnfc-common-lib.so.1: unexpected reloc type 0x03) Hi there. I don't know the cause but I'm suspicious of a few things. Could you try the following builds? The most likely: * Without -mapcs * Without -fstack-protector --param=ssp-buffer-size=4 Less likely: * Without -fno-common * With -fPIC instead of -fpic (should make no difference on ARM) Could you also send through the linker command line? It would be great to get a full log up on pastebin or similar. -- Michael

13 years, 6 months

1
0
0 0

Re: Re: unexpected reloc type 0x03 error with gcc-4.6.4 (2012.10 version)

by 남관우

13 years, 6 months

1
0
0 0

unexpected reloc type 0x03 error with gcc-4.6.4 (2012.10 version)

by Kyungmin Park

Hi Michael, Recently I tested the linaro toolchain gcc-4.6 version and try to build our codes. it's okay to compile the codes, but when launching the binary it occures following messages. /usr/lib/libnfc-common-lib.so.1: unexpected reloc type 0x03 I tested it both "hard float" and "soft float". the result is same. do you have any clues? Test environment: toolchain: gcc-4.6.4 (2012.10 version) soft float option. Thank you, Kyungmin Park

13 years, 6 months

2
2
0 0

linaro toolchain

by zhangzhangwei

hi, I use beaglebone ,and the CPU is AM3359 from TI can I use the linaro toolchain to the u-Boot linux kernel and android files?if I can ,which tool chain you suggest you use. other question, your android realese file also can use my CPU(AM3359),Can I build image and download to my SD and run it? thanks for your reply. zhangzhangwei 2012-11-09

13 years, 6 months

2
1
0 0

[ACTIVITY] 5 - 9 November

by Yvan Roux

== Progress == * Watched some Connect sessions (ARMv8, GCC performance) * AArch64 GDB support testing and backport investigation: - Activities blocked until patches with the pthread interface update are ready. * Boehm GC AArch64 support: - Read documentation on the garbage collector and ARMv8. - Asked for advices to the maintainers. - Started to port the libatomic_ops. == Next == * Continue on the Boehm GC AArch64 support.

13 years, 6 months

1
0
0 0

[ACTIVITY] report week 45

by Peter Maydell

* Attended LinuxCon Europe / ELC-Europe / QEMU Summit / KVM Forum (an overlapping set of conferences across a week in Barcelona) LCE/ELC: brief summary of interesting sessions (I've only listed ones which seem most relevant to ARM just to keep the length of this report down): * "Devicetree and its stumbling blocks" -- a view from a kernel developer perspective of some of the issues with doing platform data to dt conversions: (a) dt is supposedly OS independent and an external ABI, implying more need for cleanliness and long term supportable interfaces. (b) conversions imply a need to generalise bindings to be usable across many devices (c) what do we do about configuration / policy choices? My take is that the kernel folks are tying themselves in knots to try to preserve the (somewhat fictional in practice) idea that any kernel will work with any older device tree blob and they'd find it easier if they declared an amnesty for breaking changes before some deadline date... * Developing and testing industrial hardware with QEMU Rather than developing/testing sw against expensive/limited availability hw, use a model -- easier automation, ability to simulate error conditions, etc. If your hardware is basically a PCI card in an x86 box QEMU's fairly easy to use for this. * UEFI Secure Boot A summary of the current status of UEFI Secure Boot: it's mandatory for Win8 hardware; Linux implication is that we need to be able to maintain simple "out of box boot off distro CD"; optionally, if we have end-to-end signed binaries we have access to environments which will end up mandating it (read: government). Fortunately people have come together to tackle this and it looks like we're in good shape. http://mjg59.dreamwidth.org/18945.html is a good summary. * Kernel report by Jonathon Corbet ARM featured fairly prominently in this stats-driven roundup: 64-bit ARM support was first listed bullet point for 3.7 features Pointed out that Linaro and other embedded-ARM kernel contributions are notably up, ARM mess has been cleaned up. KVM Forum: * Concurrency in QEMU Plans for splitting QEMU's "big lock" into finer grained mutexes; should improve I/O scalability for KVM guests and realtime guest latency. However some tricky locking design issues to be solved. I am as usual sticking my oar in occasionally to remind people that the world is not solely x86-and-PCI... * qtest A summary of QEMU's new qtest framework, how it works and how to write tests. We're going to start insisting on test cases for new patches, so I need to write some basic tests for a few ARM devices so I know how it works :-) * ARM Virtualization for the Masses Christoffer Dall's talk introducing the ARM virt. extensions and KVM work. Well received, various questions afterwards (some elements of "why doesn't this work the way the x86 stuff does", also lots of "does this work on the Samsung/Google Chromebook" :-)) QEMU Summit: * This was an invite-only afternoon with perhaps 20 or so of the main QEMU contributors; broadly focused on "process" issues like release management, patch flow and security bug handling. Productive session; minutes should be available on the QEMU mailing list shortly. This is likely to be repeated next year. Informal discussions (IME the most important and worthwhile part): * virtio related : ran through current status of virtio-mmio patches with Anthony Liguori and Alex Graf, confirmed what changes we need to make and what the next steps with this should be. Some enthusiasm for getting this patchset in in the early part of the QEMU 1.4 release if we can. I'm really happy that we've unblocked this bit of work which had stalled slightly trying to figure out the right approach. Long term we will probably end up using virtio-pci on ARM but this is really dependent on hardware with good PCI support appearing. * SystemC : the upstream community is not currently interested in SystemC support, but there is some work on the QEMU core which would be a useful cleanup for QEMU itself and also useful for the SystemC folk. I'm hopeful that this might help to bring people working with QEMU in SystemC closer to the "QEMU upstream" community and mailing list, but it will be a gradual process both socially and technically if it does happen. * an informal enquiry about whether system emulation of virt. mode in ARM was planned or how much work it would be * in-kernel-irqchip: common ABI cross architecture the current ABI is a bit x86-specific, useful discussion about what POWER/S390/ARM would need. There will probably be some more ioctls coming along but the good news is that what the KVM ARM patches have currently fits into the proposals with only a very trivial tweak; we can add support for the new ioctls later if they are useful for us. -- PMM

13 years, 6 months

1
0
0 0

[ACTIVITY] 5 - 9 November

by Matthew Gretton-Dann

== Blueprints == Initial Current Actual initial-aarch64-backport 31 Oct 2012 30 Nov 2012 aarch64-baremetal-testing 31 Oct 2012 30 Nov 2012 fix-gcc-multiarch-testing 31 Dec 2012 31 Dec 2012 backport-fma-intrinsic 31 Dec 2012 31 Dec 2012 fused-multiply-add-support 31 Dec 2012 31 Dec 2012 gcc-investigate-lra-for-arm 31 Dec 2012 31 Dec 2012 == Progress == * Returned from Connect and followed up. * Updated performance blueprints for next iteration * Backporting Doko's triplet patches to 4.7 * Patches ready except for problems building Ada * HOT/COLD partitioning * Rebuilt with TBB/TBH disabled always * Started investigated LRA for ARM == Next Week == * Post triplet backport patches upstream * Run HOT/COLD partitioning benchmarks * On ARM to see if TBB/TBH is making the difference previously seen * On x86_64 to see what the actual benefit we could get * initial-aarch64-backport & aarch64-baremetal-testing * Finish documentation * gcc-investigate-lra-for-arm * Benchmark on x86_64 to see what the benfit could be. * fix-gcc-multiarch-testing * Come up with strawman proposal for updating testsuite to handle testing with varying command-line options. == Future == * backport-fma-intrinsic & fused-multiply-add-support * Backport patches once fix-gcc-multiarch-testing has been done. -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-dann(a)linaro.org

13 years, 6 months

1
0
0 0

Compilation speed of Linaro's gcc compared to e.g. Ubuntu's version

by "Frank Müller"

Dear all, we have an ARM Cortex-A8 board where we are running our application. I am in charge of maintaining the Linux on it and the toolchain/SDK setup. So far we've been running Poky/OpenEmbedded and using the cross compiler that came about during the compilation. For easier maintenance, we are now switching to Linaro. The image is set up and I can compile, however I notice a peculiar fact: the binary distribution of Linaro's gcc (https://launchpad.net/linaro-toolchain-binaries/trunk/2012.10/+download/gcc…) has a significantly larger compilation speed than a version of arm-linux-gnueabihf-gcc that is shipping with Ubuntu. In our particular case, using Ubuntu's version it takes less than 6 minutes to compile our software, but 10 minutes when we use Linaro's version. The makefiles and source are exactly the same, only the compiler is different. I also tried an older version (4.6) of Linaro's gcc to match the Ubuntu one (tested the 12.04 shipped version), with no significant difference. Compiler flags for the system are -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=hard Running with -ftime-report, most of the additional time seems to be spent in the parser. Adding -fno-graphite-identity -fno-graphite for Linaro's gcc did not make a difference. I believe I tried to use crosstool-ng to make my own version, but I don't remember the results as this was over 7 weeks ago. I also did not have a chance to compare performance of the binaries. I do notice a difference in compilation sizes (4.8 MB for Ubuntu's 4.6 version, 4.1 MB for Linaro's 4.7 versions - can't test anything other right now). I would like to use Linaro's gcc as the crosscompiler for our project, as it is an easy setup. Repackaging Ubuntu's version is an option, though (some of the team do not use Ubuntu, plus I'd like everybody to use EXACTLY the same version of the crosscompiler). So there is no real "problem" for me, per se, but I am extremely curious as to what is going on here. It seems that Linaro's gcc has additional patches or maybe just different default settings that cause additional time to be spent in the parser. It would be interesting to know what exactly this is and whether/how it can be disabled in those cases where time of compilation is more important than e.g. performance gain. TIA for replying. Best Frank

13 years, 6 months

3
7
0 0

Initial aarch64 plans

by Michael Hope

This is the first of a few Connect follow up emails. KVM and Cortex-A15 tuning are to come. Matt and I have entered the initial aarch64 blueprints. These are part of the bootstrap that clear the way for us and the community to port packages on top. The high priority ones are: * Add support for AArch64 to Boehm GC[1] * Add support for GProf to AArch64 backend of GCC[2] After those we have: * Add IFUNC support for AArch64[3] * AArch64 GCC support for Stack Protection[4] All are linked off the parent blueprint at: https://launchpad.net/gcc-linaro/+spec/aarch64-gcc-initial-meta and we'll add more there as time goes by. The plan is to commit to the first two and do them this iteration. The latter two aren't critical and will be done as part of our general work. -- Michael [1] https://launchpad.net/linaro-toolchain-misc/+spec/aarch64-boehm-gc [2] https://launchpad.net/gcc-linaro/+spec/aarch64-gcc-gprof-support [3] https://launchpad.net/binutils-linaro/+spec/aarch64-gcc-ifunc [4] https://launchpad.net/gcc-linaro/+spec/aarch64-gcc-ssp-support

13 years, 6 months

1
0
0 0

[ACTIVITY] report week 44

by Peter Maydell

* Attended Linaro Connect; notable sessions: + Ubuntu plans for QEMU for Ringtail release = upstream qemu has merged qemu-kvm back in so Ubuntu will switch to qemu from qemu-kvm for x86 = also makes sense now to use upstream qemu for all archs (following Debian) rather than using qemu-linaro for non-x86: reasons for using q-l in Ubuntu now mostly fixed (ie upstream ARM support no longer dire). Ubuntu will carry omap3 patches to avoid dropping that feature in the changeover = makes sense for Linaro too as we now have an automated package-to-PPA setup for people who need bleeding-edge and also will want Ubuntu to transition to a more stably released and supported QEMU codebase to use for KVM-on-ARM-servers + KVM Testing plans = worked through a list of things that would be nice to test; useful feedback from people in the session about what matters. Missing: specific commitment by anybody to write tests :-) + various informal discussions about possibilities for v8 QEMU * this week: at LinuxCon Europe / ELC-Europe / KVM-Forum / QEMU Summit -- PMM

13 years, 6 months

2
1
0 0

Daylight savings changes

by Michael Hope

Hi toolchain people, I've gone through and massaged our meetings and 1-on-1s to handle the recent daylight savings changes. Most meetings now start at 9:15 am GMT and 1-on-1s are packed before them if possible. Let me know if I should massage them further, -- Michael

13 years, 6 months

1
0
0 0

[ACTIVITY] 29 Oct - 2 Nov

by Matthew Gretton-Dann

== Progress == * Attended Linaro Connect * Worked out focus for performance in next iteration: * Cortex-A15 * Other discussions on: * Transitioning from cbuild->LAVA * ARMv8 GNU Tools support * big.LITTLE Toolchain tuning == Next Week == * Backport Doko's configury changes for arm-none-linux-gnueabihf support * Remerge HOT/COLD partitioning to test like for like (TBB generation) * Benchmark LRA vs Reload on x86 and x86-64 * Write up strawman for non-multitest testing in GCC == Future == * Decide whether the effort to develop HOT/COLD partitioning is worth it. * Support LRA on ARM. * Attend Connect in Hong Kong... -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-dann(a)linaro.org

13 years, 6 months

1
0
0 0

ARM cross mismatch error

by naveen yadav

Dear All, We have ARM cross compiler, and building our code. we got below error. we have GCC Linaro 4.6.4. arm-linux-gnueabi/bin/ld: DIV usage mismatch between /home/Release/libasm.a(Blt32_Neon.o) and /home/Release/liblayer.so arm-linux-gnueabi/bin/ld: failed to merge target specific data of file /home/Release/libasm.a(Blt32_Neon.o) is it related to below link ? http://sourceware.org/ml/binutils/2012-03/msg00211.html thanks

13 years, 6 months

2
1
0 0

Some ugly patches for gcc-linaro on Android

by Bernhard Rosenkränzer

Hi, here's some patches for gcc-linaro to make it work with --host=arm-linux-androideabi They're the quick and dirty thing to do and look like they could have been written by Microsoft, needed something working in time for Connect ;) gcc-4.7-android-workarounds.patch: Workarounds for things that go wrong, but where the true cause is yet to be determined (e.g. why would configure think we have fread_unlocked and friends when we don't?) gcc-4.7-libitm-android.patch: Workaround for Bionic not knowing Elf32_auxv_t gcc-4.7-no-unneeded-multilib.patch: Get the multilib config in sync with regular Linux gcc-4.7-stlport.patch: Use stlport instead of libstdc++ (yes, this sucks - but it's what Android decided to do). Still needs to link libstdc++ because Bionic contains a libstdc++.so (but it's more like a libsupc++ - no STL there, but needed for stlport to work). ttyl bero

13 years, 6 months

2
1
0 0

[ACTIVITY] 22-26 October

by Matthew Gretton-Dann

== Progress == * HOT/COLD partitioning for PGO * Initial look at results * Patch Tracking & Backporting * Testing Doko's configury changes for arm-none-linux-gnueabihf support * Connect Prep * LRA Investigations * Sign/zero extension II == Next Week == * Linaro Connect == Future == * Attend Connect * HOT/COLD partitioning for PGO: * Get two current patches accepted upstream * Post question upstream about register allocation 'mistakes' I am seeing -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-dann(a)linaro.org

13 years, 6 months

1
0
0 0

[Activity] Week 43

by Zhenqiang Chen

Summary: * Validate and release Linaro binary toolchain 2012.10 * Test Details: 1. Release Linaro binary toolchain 2012.10 * Fix windows installer issue due to version format change. * Validate and release Linaro binary toolchain 2012.10. 2. Identify the root cause of PR 54902 (lp:1065559), and Richard Biener fixed it. 3. Enable SPEC2006 test. Testing is ongoing. Planed Leaves: * Nov. 5-7: Off site teambuilding event. * Nov. 9, 12-13: Annual leaves Plans: * Performance test for shrink-wrap. Best regards! -Zhenqiang

13 years, 6 months

1
0
0 0

[Activity] October 22-26

by Christophe Lyon

== Progress == * PGO/hot-cold partitioning/Spec2k: * Debugging why 254.gap is causing an ICE. * Connect preparation: Still preparing a temporary laptop * Internal stuff == Next == * Connect

13 years, 6 months

1
0
0 0

[ACTIVITY] report week 43

by Peter Maydell

== track-kvm-abi-changes == * updated qemu patches to match Christoffer's v13 tree, committed all fixes suggested in previous round of code review, rebased and sent RFC v3 of the QEMU KVM/ARM support patches == other == * rebased qemu-linaro on master; found and fixed a bug which meant that beagle models crashed when the kernel tried to touch the USB-OHCI device * submitted some minor QEMU cleanup patches (last lot of stuff before softfreeze next week, I expect) * usual upstream review/etc * started to look at virtio-mmio patches * prep for Linaro Connect next week KVM blueprint progress tracker: http://ex.seabright.co.nz/helpers/backlog?group_by=topic&colour_by=state&pr… -- PMM

13 years, 6 months

1
0
0 0

[ACTIVITY] 22-26 October

by Yvan Roux

== Progress == * Aarch64 GDB support testing: - Ran the GDB testsuite via gdbserver on x86 - Made a board file to run against the model - Tried debugging a simple hello world via gdbserver: It fails while loading the image, because of a mismatch between kernel and GDB ptrace interface. * Aarch64 GDB backport investigation: - Backported to the Linaro GDB 7.5 release. - Discussed with ARM people the ptrace issue. == Next == * On vacation.

13 years, 6 months

1
0
0 0

[ANNOUNCE] Linaro Toolchain Binaries 2012.10 released

by Zhenqiang Chen

The Linaro Toolchain Working Group is pleased to announce the 2012.10 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.10 * Linaro GDB 7.5 2012.09 * 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.10 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.

13 years, 6 months

1
0
0 0

Test Case to verify the support of VFPV3 and VFPV4

by Jubi Taneja

Hi All, I wanted to see the difference in objdump of an application where I can make the difference between the VFPV3 and VFPV4 support. I tried enabling the flag -mfpu=vfpv3 and -mfpu=vfpv4 for ARM Cortex A15 toolchain in my test code but cannot see the difference in two objdumps. According to my survey, the fused multiply and accumulate is the only instruction that can create the difference in two. Can any one provide the sample test code for the same? Precisely, I wish to see the difference in performance for vfpv3 and vfpv4. Looking forward to your reply. Thanks and Regards, Jubi

13 years, 6 months

4
13
0 0

[Activity] Week 42

by Zhenqiang Chen

Summary: * Linaro bug analysis * Validation Details: 1. Linaro bug analysis: * lp:1065122: Triaged. A fix patch was committed to 4.7 and trunk. * lp:1065559: Confirmed. Need more investigation to find the root cause. * lP:1065509: Can not reproduce it with the latest Linaro toolchain. * lp:1066095: Investigate and invalid it since the reporter can not reproduce it now. 2. Bug fix and smoke test for Linaro binary toolchain 2012.10 release. 3. Clean up shrink-wrap related patches and send to Linaro mail-list for review. Plans: * Linaro binary toolchain 2012.10 release. * Shrink-wrap performance test. Planed leave: * Oct. 26 Best regards! -Zhenqiang

13 years, 6 months

1
0
0 0

[ACTIVITY] 15-19 October

by Yvan Roux

== Progress == * Read wikis on OpenEmbedded and FastModel * Aarch64 GDB support testing : - Managed to run OE rootfs and kernel under FastModel - Configured the ssh/scp access to the model * Aarch64 GDB backport investigation : - Discussed with ARM the port and plans - Identified upstream patches == Next == * Continue on Aarch64 GDB.

13 years, 6 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain