- linaro-toolchain - lists.linaro.org

"BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0) " assert

by Barry Song

Hi All, I found Jie has committed a patch "http://sourceware.org/ml/binutils/2010-05/msg00083.html". I am using the newest binary utils(2.21) and encounted the following ASSERT in arm_elf32.c: + if (out_attr[i].i == 0) + { + BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0); My compiling options are as below, ASM_FLAGS := \ -gdwarf-2 \ -mfpu=vfp \ -mfloat-abi=softfp \ -mthumb-interwork C_FLAGS := \ $(ASM_FLAGS) \ -O3 -Wno-all \ -fno-optimize-sibling-calls \ -mlong-calls \ -ffunction-sections \ CPP_FLAGS := \ -fno-rtti \ -fno-exceptions \ LINK_FLAGS := \ --gc-sections -nostdlib \ -L ../stdlib \ -Wl,--as-needed \ -Wl,-no-enum-size-warning \ --cref \ ARFLAGS := \ rcs Can anyone give me any tip about why the assert is triggered? I have reported a bug here: http://sourceware.org/bugzilla/show_bug.cgi?id=12700 But not sure whether it is a bug. -barry

14 years, 6 months

4
10
0 0

__aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko

by Barry Song

Hi All, I am using 2011.3 4.5 linaro GCC(armv7-a vfpv3d16) to compile kernel and modules. I select to compile all codecs as modules: "config SND_SOC_ALL_CODECS tristate "Build all ASoC CODEC drivers" " as M and I2C/SPI too. Then in the kernel dir, run "make" to get both vmlinux and modules, I found snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko will fail due to "__aeabi_uldivmod undefined". If i comment do_div() in these codec drivers, this issue will disappear. But it is strange there are many codecs which use do_div() too, for example: sound/soc/codecs/max98088.c sound/soc/codecs/max9850.c sound/soc/codecs/wm8350.c sound/soc/codecs/wm8400.c sound/soc/codecs/wm8510.c sound/soc/codecs/wm8580.c sound/soc/codecs/wm8753.c sound/soc/codecs/wm8804.c sound/soc/codecs/wm8900.c sound/soc/codecs/wm8904.c sound/soc/codecs/wm8940.c sound/soc/codecs/wm8955.c sound/soc/codecs/wm8960.c sound/soc/codecs/wm8974.c sound/soc/codecs/wm8978.c sound/soc/codecs/wm8985.c sound/soc/codecs/wm8990.c sound/soc/codecs/wm8991.c sound/soc/codecs/wm8993.c sound/soc/codecs/wm8994.c sound/soc/codecs/wm8995.c sound/soc/codecs/wm9081.c but others can pass the compiling except those 3 modules. Is it due to a wrong optimization by gcc? Other information: 1. old tool-chains we are using can pass the compiling of the 3 modules. 2. If i built all codecs into kernel image, these 3 drivers don't report error while compiling. Thanks Barry

14 years, 6 months

5
18
0 0

Re: [alsa-devel] [PATCH] ASoC: prevent compilers from optimising pll calculation into __aeabi__uldivmod

by Barry Song

2011/4/27 Mark Brown <broonie(a)opensource.wolfsonmicro.com> > > On Wed, Apr 27, 2011 at 04:50:12PM +0800, Barry Song wrote: > > > Marking pll_factors() as noinline or putting asm("" : "+r"(source)); before the > > call to do_div() works around the problem. > > If we do have to do something in the callers rather than in do_div() the > annotation seems substantially more taseful than inserting a random asm > into the code. I agree. for this patch which will not be applied, people can just get information about how to workaround the gcc issue while they have the same problem. google can find there are other people who failed to compile wm8974 module too. eg. http://irclogs.ubuntu.com/2010/03/30/%23ubuntu-arm.txt Andrew Stubbs, Michael Hope in Linaro's toolchain team are working hard on this gcc issue. there have been many update today: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783

14 years, 6 months

3
5
0 0

-O2 cause optimization issues while va parameters functions

by Barry Song

Hi All, As i have frequently said, we are using 2011.3 4.5 linaro gcc. For the following codes, if we compile it by -O2, it will crash with "segment fault", if we just comment " if(unifi_debug >= level) {", all will be ok. If we don't compile it by -O2, all will be ok too. #include <stdlib.h> #include <stdio.h> #include <stdarg.h> #define DEBUG_BUFFER_SIZE 80 int unifi_debug = 5; void unifi_trace(void* ospriv, int level, const char *fmt, ...) { static char s[DEBUG_BUFFER_SIZE]; va_list args; unsigned int len; if(unifi_debug >= level) { va_start(args, fmt); len = vsnprintf(&(s)[0], (DEBUG_BUFFER_SIZE), fmt, args); va_end(args); if (len >= DEBUG_BUFFER_SIZE) { (s)[DEBUG_BUFFER_SIZE - 2] = '\n'; (s)[DEBUG_BUFFER_SIZE - 1] = 0; } printf("%s", s); } } int main(void) { char *prog = "/usr/sbin/unififw"; unifi_trace(NULL, 1, "start %s\n", prog); return 0; } Thanks Barry

14 years, 6 months

3
5
0 0

Sessions for the summit

by Michael Hope

Hi there. A first-pass list of summit sessions is up at: https://wiki.linaro.org/MichaelHope/Sandbox/1111Blueprints The next step is to investigate these areas and come up with a basic plan that can be discussed during the summit. I've put your names against the sessions as follows: Andrew: Broad tuning Dave: String routines everywhere Dave: QEMU topic #2 Doug: STM support Ira: Vectoriser and NEON performance Ken: 64 bit sync primitives Ken: Good backtracing Ken: End-developer tools bluesky Michael: Publish benchmarking of the toolchain Michael: Binary builds Michael: Deeper validation Peter: QEMU bluesky Ramana: Thumb-2 performance brainstorm Ramana: GCC backend rework Ulrich: GDB as a cross-debugger Ira and Dave, I know you won't be at the summit but we'll see about being able to call in. Could you all please have a read of the outline, investigate these topics, and draft up a blueprint-style list of work items to achieve it? Record any notes in the sandbox page[5] or in a child page if needed. Larger topics may warrant a specification[1]. I'd like these done by the end of next week. I'd expect to spend up to a day on the topics you already understand and more on broad topics. For reference, the see the draft TRs[2] and spreadsheet [3]. I've added some GDB topics to the spreadsheet that still need to go onto the wiki page. The outlines should touch each of these TRs in some way so let me know if I've missed anything. There's more good information on the process and style at: https://wiki.linaro.org/Process/Blueprints https://wiki.linaro.org/Process/WorkItemsHowto https://wiki.linaro.org/Resources/FAQ Questions? Need more detail? Let me know. -- Michael [1] https://wiki.linaro.org/Process/SpecTemplate [2] https://wiki.linaro.org/Cycles/1111/TechnicalTopics/Toolchain [3] https://spreadsheets.google.com/ccc?key=0Ap7fWLePADFVdHkxYy1INTZmMEd4bkwxSG… [4] there is no 4... [5] https://wiki.linaro.org/MichaelHope/Sandbox/1111Blueprints

14 years, 6 months

2
1
0 0

[ACTIVITY] 18th - 21st April

by Andrew Stubbs

Merged & tested the outstanding merge requests into Linaro GCC. Spin the Linaro GCC 4.5 and 4.6 releases. Uploaded the tarballs to Michael. Submitted a patch upstream that removed some redundant code that had confused me a introduced a bug into my Thumb2 constants patch. http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03756.html This patch is now approved and committed upstream. I'll commit it internally when the rest of my ARM/Thumb constant handling changes are upstream. Worked on addressing RichardE's concerns with my Thumb2 constants patch. Tried to split it into smaller chunks, and rename the constraints. Posted the patches upstream: 1. a small patch upstream to clean up MOWV support. http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03768.html (Now approved and committed.) 2. ADDW and SUBW support. http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03783.html 3. Replicated constants for constant splitting. http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03883.html Committed upstream Dan's Vector shift test cases patch that was approved last week. Pushed the same patch to Linaro GCC 4.6. ---- Upstream patched requiring review: * NEON scheduling patch http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html * ARM EABI half-precision functions (reposted 2011-04-14) http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03210.html * ARM Thumb2 addw/subw support. http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03783.html * ARM Thumb2 Replicated constants http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03883.html

14 years, 6 months

1
0
0 0

Performance meeting agenda for today.

by Ramana Radhakrishnan

Hi, Agenda for today's performance call . Sorry about the last minute posting and I'll put this in the wiki soon enough. 1. Sync-up on what's been happening around the group: a. Coremark regressions. b. Thumb2 constants patch. c. divmodsi4 and vfp register moves. d. DENBench investigations. 2. Planning for the summit and turning some of the ideas into blueprints. 3. AOB. cheers Ramana

14 years, 6 months

1
0
0 0

[ACTIVITY] Apr.18 -- Apr.24

by Chung-Lin Tang

== Last week == * PR48250, rehaul arm_legitimize_reload_address(). Richard Sandiford caught a bug of mine where I overlooked the valid index range of NEON quad-word load/stores. Quickly whipped up a fix, soon approved and committed upstream. * LP #744754, ICE in NEON struct-mode auto-inc-dec MEMs. Pushed upstream patch for a merge to Linaro 4.5. * PR46888, bit-field insert optimization patch. Resumed investigating, mailed Andrew Pinski for more information on that REG_EQUAL note issue he mentioned on gcc-patches; can't quite reproduce it myself. * CoreMark ARMv6/v7 regressions: posted a patch set to gcc-patches. Still waiting review. * Reported to Bernd and AndrewS on an issue (LP #748138) which seems to be related to the shrink-wrap patch. This ICE does not seem to be avoided by doing -fno-shrink-wrap. * A few tasks related to Linaro-Budapest event travel. == This week == * Do the merge of the new combine patches to Linaro, and test. * LP #689887 is still in progress. * Hope to experiment with a few more optimization ideas.

14 years, 6 months

1
0
0 0

NEON intrinsics vs. assembly code

by Richard Sandiford

Michael mentioned that some users reported seeing better preformance from RVCT using arm_neon.h then they did when coding directly in assembler. He suggested we try the same thing for GCC. Here's an experiment using the example that Jim Huang posted to the dev list recently: https://wiki.linaro.org/RichardSandiford/Sandbox/IntrinsicsPerformance The summary is that the C version needs to borrow a trick from the assembly code in order to be competitive. If it does that, though, the C code can be faster. I think this is mostly down to scheduling, although I haven't checked in detail yet. Richard

14 years, 6 months

2
1
0 0

[ACTIVITY] 2011-04-21

by David Gilbert

== String and Memory routines == * Profiled denbench with perf and produced a set of stats to show which programs spent how much time in libc and how much time was spent in each routine. While some of the benchmarks are good (like aes) and spend almost no time in libc some of the others (MPEG codecs especially) seem to spend significant times in libc. * Ran all of denbench through latrace to generate sets of library calls; post processed them to extract the section between the clock() calls (and hence in the timed portion) and analysed the hot library calls. I've looked at some of the output but not all of it yet; I get output like: Memcpy stats (dst align/src align/length/number of occurrences/total size copied) memcpy: 0,0,1 , 1588520, 1588520 memcpy: 16,28,4096 , 1, 4096 memcpy: 4,20,16384 , 855, 14008320 This shows that for a bunch of tests they do an inordinate number of 1 byte memcpy's, and a few hundred larger memcpy's with an address %32 which is 4 (and destination %32 is 20) - so not aligned but at least equally misaligned. * Started writing up a report on some of the stats * Also started to try and extract the same stuff from SPEC2k6 == QEMU == * Tested Peter's QEmu release earlier in the week (On Lucid so didn't hit his natty bug) * Wrote up a couple of specs (one for TrustZone and the other for Device Tree integration)

14 years, 6 months

1
0
0 0

[ACTIVITY] Weekly status

by Revital Eres

Hello, Submitted the following patches to GCC trunk: [1] Avoid unfreed memory when SMS fails (committed to trunk GCC) - http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01204.html [2] Free sccs field (committed to trunk GCC)- http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01205.html [3] New flag to apply SMS when SC equals 1 (committed to trunk GCC) - http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01293.html [4] Avoid considering debug_insn when calculating SCCs - http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01294.html [5] Support instructions with REG_INC_NOTE - http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01309.html Returned looking into DENbench's benchmarks. Thanks, Revital

14 years, 6 months

1
0
0 0

[ACTIVITY] Apr 18 - Apr 21

by Ulrich Weigand

== GDB == * Created Linaro GDB 7.2-2011.04-0 release. * Committed patch to fix accessing "fpscr" register to Linaro GDB. * Failure to disable address space randomization (bug #616001) has been fixed in the kernel; closed the Linaro GDB bug. == GCC == * Ongoing analysis of bug #759409 (Profiled bootstrap fails). Identified two independent problems, one related to a new CodeSourcery feature, and one a mis-optimization of final-stage cc1plus which is also present in FSF GCC 4.5 (PR 43085). Ongoing investigation to track down the root cause of the latter problem. == Schedule == * Public holidays 04/22 - 04/25. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

14 years, 6 months

1
0
0 0

[ACTIVITY] report week 16

by Peter Maydell

RAG: Red: Amber: Green: another monthly qemu-linaro release out on schedule Current Milestones: | Planned | Estimate | Actual | qemu-linaro 2011-04 | 2011-04-21 | 2011-04-21 | 2011-04-21 | Historical Milestones: finish qemu-cont-integration | 2011-01-25 | 2011-01-25 | handed off | first qemu-linaro release | 2011-02-08 | 2011-02-08 | 2011-02-08 | qemu-linaro 2011-03 | 2011-03-08 | 2011-03-08 | 2011-03-08 | == maintain-beagle-models == * qemu-linaro 2011.04 tested and released * had to do another last minute -1 respin to fix a problem caught by ubuntu package builds; we need to come up with a process that lets us do test package builds prior to release so we can fix this sort of issue in a less last-minute fashion == merge-correctness-fixes == * sent patch: fix semihosting SYS_HEAPINFO (seems to have issues though) * sent patch: UNDEFs in Neon load/store space * sent patches: fix build issues on sparc * sent patch: bump the initrd load address to work with bigger kernels * sent patch: set Invalid flag for float-to-int conversion of NaN * sent patch: move vld/vst multiple to helper functions * reviewed patches from Aurelien doing some general softfloat cleanup * sent out a version of my performance counters patch which just does a basic dummy implementation without the cycle counter (since the cycle counter bits were going off down a blind alley rather and this part is the last thing needed to be able to boot Linaro vexpress images on stock upstream QEMU) == other == * trying to nail down proposed QEMU work for next cycle; work-in-progress: https://wiki.linaro.org/PeterMaydell/Qemu1111 * meetings: toolchain, standup Current qemu patch status is tracked here: https://wiki.linaro.org/PeterMaydell/QemuPatchStatus Absences: Holiday: 22 Apr - 2 May 9-13 May: UDS, Budapest (maybe) 15-16 August: QEMU/KVM strand at LinuxCon NA, Vancouver [LinuxCon proper follows on 17-19th]

14 years, 6 months

1
0
0 0

[ACTIVITY] weekly status

by Ken Werner

Hi, libunwind: * added initial support for resuming at a certain stack frame * posted unw_resume support plus some some testsuite fixes on the ml * there are still some issues left if signal handlers/frames are involved Note: Friday is a public holiday. Regards Ken

14 years, 6 months

1
0
0 0

[ACTIVITY] Weekly status

by Richard Sandiford

== This week == * Iterated with upstream on some of the vectorisation patches. I think only half a patch (the ARM implementation of array_mode_supported_p) is still pending review; everything else has been approved. * Backported the vldN and vstN intrinsics to Linaro 4.5. * Finished off the microbenchmarks for libav. * One of the problems in the original libav output was that the vectoriser didn't realise that a group of N accesses really did form a group. It instead generated N separate interleave operations and took 1 vector from each. Submitted a fix for that, which is now committed upstream. Updated the libav wiki page with the new, improved output. (This actually allowed more libav loops to be vectorised, as well as improving the output from some of the existing ones. I haven't looked at the new ones. I expect this comes from interleaved stores.) * Wrote an arm_neon.h version of Android's scanline_t32cb16_neon and compared it with the original. * Started (and only started) seeing how the vectorisation stuff affects DENbench. * Backported the dwarf2out OOM fix to Linaro 4.6. == Next week == * Do something useful on DENbench. * If all goes well, commit the vectorisation work upstream and backport it to Linaro 4.5 and 4.6. ...but it's only a three day week. Richard

14 years, 6 months

1
0
0 0

Linaro QEMU 2011.04-1 released

by Peter Maydell

The Linaro Toolchain Working Group is pleased to announce the release of Linaro QEMU 2011.04-1. Linaro QEMU 2011.04-1 is the third release of qemu-linaro. Based off upstream (trunk) qemu, it includes a number of ARM-focused bug fixes and enhancements. Interesting changes include: - Compiling for an ARM host in Thumb mode now works - As usual, various minor correctness fixes and other upstream changes Known issues: - The beagle and beaglexm models do not support USB, so there is no keyboard, mouse or networking (#708703) The only change over the shortlived 2011.04-0 is to fix a compilation failure with gcc 4.5. The source tarball is available at: https://launchpad.net/qemu-linaro/+milestone/2011.04-1 Binary builds of this qemu-linaro release are being prepared and will be available shortly for users of Ubuntu. Packages will be in the linaro-maintainers tools ppa: https://launchpad.net/~linaro-maintainers/+archive/tools/ More information on Linaro QEMU is available at: https://launchpad.net/qemu-linaro

14 years, 6 months

1
0
0 0

Linaro GDB 7.2 2011-04 released

by Michael Hope

The Linaro Toolchain Working Group is pleased to announce the release of Linaro GDB 7.2. Linaro GDB 7.2 2011.04 is the fifth release in the 7.2 series. Based off the latest GDB 7.2, it includes a number of ARM-focused bug fixes. This release fixes: * LP: #684218 Failure to backtrace out of glibc system call stubs * LP: #667309 failed to single step over bad thumb->arm boundary * Fix accessing "fpscr" register The source tarball is available at: https://launchpad.net/gdb-linaro/+milestone/7.2-2011.04-0 More information on Linaro GDB is available at: https://launchpad.net/gdb-linaro -- Michael

14 years, 6 months

1
0
0 0

Linaro GCC 4.5 and 4.6 2011-04 released

by Michael Hope

The Linaro Toolchain Working Group is pleased to announce the release of both Linaro GCC 4.5 and Linaro GCC 4.6. Linaro GCC 4.5 2011.04 is the ninth release in the 4.5 series. Based off the latest GCC 4.5.2+svn171921, it adds new optimisations, support for Android, and fixes for many of the issues found in the last month. Linaro GCC 4.6 2011.04 is the second release in the 4.6 series. Based off the latest GCC 4.6.0+svn171921, it is the first supported release of the new series and includes a significant number of mainstreamed patches from 4.5. Interesting changes in 4.6 include: * Updates to 4.6.0+r171921 * Adds conditional store sinking to the vectoriser * Brings in a significant number of the Linaro GCC 4.5 patches that are in mainline Interesting changes in 4.5 include: * Updates to 4.5.2+r172013 * Disables the shrink wrap optimisation by default * Adds support for swing-modulo scheduling (SMS) on ARM * Adds support for Android and the Bionic C library * Optimises -fvar-tracking, greatly reducing memory used when compiling large files (seen in QEMU) Fixes: * 'volatile' being ignored on volatile struct members * A potential register clobber in arm_negdi2 * An error in libgcc that prevented it being built with -Os * Multiple shrink wrap bugs (LP: #731665, 721023, 736081, 758082, 730860, 736439, 721023) * LP: #730440 incorrect immediate for movt (seen in Firebird) * LP: #728315 extension elimination pass mishandles subregs of promoted variables (seen on MIPS) * LP: #675347 volatile int causes inline assembly build failure (seen in Qt) SMS is an optimisation that works on innermost loops and reorders the instructions by overlapping different locations. An example is that the values for the next loop may be loaded during the current loop, making the values already ready when the next loop starts. SMS is disabled by default. To try it, add the options '-fmodulo-sched -fmodulo-sched-allow-regmoves'. The source tarball is available from: https://launchpad.net/gcc-linaro/+milestone/4.5-2011.04-0 https://launchpad.net/gcc-linaro/+milestone/4.6-2011.04-0 Downloads are available from the Linaro GCC page on Launchpad: https://launchpad.net/gcc-linaro -- Michael

14 years, 6 months

1
0
0 0

[OT] ti-omap-tools - script for setting up DVSDK 3 with various toolchains

by AJ ONeal

Here's a script for installing TI's DVSDK 3: https://bitbucket.org/thayne/ti-omap-tools/src Works with - CodeSourcery - OpenEmbedded - Linaro It will download the bazillion dependencies scattered across TI's site and makes it easier to gut the DVSDK's hard-coded paths to work for your setup. The DVSDK 4 isn't used because it is completely different from the DVSDK 3 and is much more difficult to root the hard paths and checks out of. AJ ONeal

14 years, 6 months

1
0
0 0

Question on compressed vmlinux .got and .bss sections

by Shawn Guo

Hi toolchain, kernel folks, I'm seeing an interesting thing on .got and .bss sections of arch/arm/boot/compressed/vmlinux, and really need your expertise to shed some lights. I have an uninitialized variable 'uart_base' defined in misc.c. static unsigned long uart_base; $ arm-linux-gnueabi-objdump -D arch/arm/boot/compressed/misc.o Disassembly of section .bss: 00000000 <uart_base>: 0: 00000000 andeq r0, r0, r0 00000004 <__machine_arch_type>: 4: 00000000 andeq r0, r0, r0 [...] And section layout looks like the following. $ arm-linux-gnueabi-objdump -h arch/arm/boot/compressed/vmlinux SECTIOINS { ... _etext = .; _got_start = .; .got : { *(.got) } _got_end = .; .got.plt : { *(.got.plt) } _edata = .; . = ALIGN(4); __bss_start = .; .bss : { *(.bss) } _end = .; ... } $ arm-linux-gnueabi-objdump -h arch/arm/boot/compressed/vmlinux arch/arm/boot/compressed/vmlinux: file format elf32-littlearm Sections: Idx Name Size VMA LMA File off Algn 0 .text 001c474c 00000000 00000000 00008000 2**5 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .got 00000028 001c474c 001c474c 001cc74c 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .got.plt 0000000c 001c4774 001c4774 001cc774 2**2 CONTENTS, ALLOC, LOAD, DATA 3 .bss 00000020 001c4780 001c4780 001cc780 2**2 ALLOC 4 .stack 00001000 001c47a0 001c47a0 001cc780 2**0 ALLOC 5 .comment 0000002a 00000000 00000000 001cc780 2**0 CONTENTS, READONLY 6 .ARM.attributes 00000031 00000000 00000000 001cc7aa 2**0 CONTENTS, READONLY I'm able to see uart_base in vmlinux objdump ... $ arm-linux-gnueabi-objdump -t arch/arm/boot/compressed/vmlinux [relevant only, and sorted] 00000000 l d .text 00000000 .text 001c474c l d .got 00000000 .got 001c4774 l d .got.plt 00000000 .got.plt 001c4780 l d .bss 00000000 .bss 003968e4 g *ABS* 00000000 _image_size 001c474c g *ABS* 00000000 _got_start 001c4774 g *ABS* 00000000 _got_end 001c4780 g *ABS* 00000000 _edata 001c4780 g *ABS* 00000000 __bss_start 001c4780 l O .bss 00000004 uart_base 001c4798 g O .bss 00000004 malloc_ptr 001c478c g O .bss 00000004 output_ptr 001c479c g O .bss 00000004 malloc_count 001c4794 g O .bss 00000004 free_mem_end_ptr 001c4788 g O .bss 00000004 output_data 001c4784 g O .bss 00000004 __machine_arch_type 001c4790 g O .bss 00000004 free_mem_ptr 001c47a0 g *ABS* 00000000 _end ... but I can not see it in the zImage (all others in .bss seem still there). $ xxd arch/arm/boot/zImage | tail 01c4740: 3ef1 1400 be52 9f58 e468 3900 4c47 1c00 >....R.X.h9.LG.. ^_got_start (why is it?) 01c4750: 9847 1c00 1043 0000 8c47 1c00 9c47 1c00 .G...C...G...G.. ^malloc_ptr ^output_ptr 01c4760: 9447 1c00 080a 0000 8847 1c00 8447 1c00 .G.......G...G.. ^free_mem_end_ptr ^__machine_arch_type 01c4770: 9047 1c00 0000 0000 0000 0000 0000 0000 .G.............. ^free_mem_ptr The following is a run-time memdump at _got_start. Before recalculation: 9056304C: 001C474C 001C4798 00004310 001C478C 001C479C 001C4794 00000A08 001C4788 ^_got_start (why is it?) 9056306C: 001C4784 001C4790 00000000 00000000 00000000 EDFE0DD0 4C010000 38000000 After recalculation (for .bss entries, the delta is 9039EA50, for others in .got, delta is 9039E900): 9056304C: 9056304C 905631E8 903A2C10 905631DC 905631EC 905631E4 9039F308 905631D8 9056306C: 905631D4 905631E0 00000000 00000000 00000000 73FBC000 4C010000 38000000 QUESTION: Where is the .bss section of uart_base? Now, I remove the 'static' to have 'unsigned long uart_base', and dump the same stuff to compare. $ arm-linux-gnueabi-objdump -D arch/arm/boot/compressed/misc.o Disassembly of section .bss: 00000000 <__machine_arch_type>: 0: 00000000 andeq r0, r0, r0 00000004 <uart_base>: 4: 00000000 andeq r0, r0, r0 I'm able to see uart_base in vmlinux objdump ... $ arm-linux-gnueabi-objdump -t arch/arm/boot/compressed/vmlinux [relevant only, and sorted] 00000000 l d .text 00000000 .text 001c4720 l d .got 00000000 .got 001c474c l d .got.plt 00000000 .got.plt 001c4758 l d .bss 00000000 .bss 003968e4 g *ABS* 00000000 _image_size 001c4720 g *ABS* 00000000 _got_start 001c474c g *ABS* 00000000 _got_end 001c4758 g *ABS* 00000000 _edata 001c4758 g *ABS* 00000000 __bss_start 001c475c g O .bss 00000004 uart_base 001c4770 g O .bss 00000004 malloc_ptr 001c4764 g O .bss 00000004 output_ptr 001c4774 g O .bss 00000004 malloc_count 001c476c g O .bss 00000004 free_mem_end_ptr 001c4760 g O .bss 00000004 output_data 001c4758 g O .bss 00000004 __machine_arch_type 001c4768 g O .bss 00000004 free_mem_ptr 001c4778 g *ABS* 00000000 _end ... and I can also see it in the final zImage. $ xxd arch/arm/boot/zImage | tail 01c4710: 221f f1b3 3ef1 1400 be52 9f58 e468 3900 "...>....R.X.h9. 01c4720: 5c47 1c00 2047 1c00 7047 1c00 e442 0000 \G.. G..pG...B.. ^uart_base 01c4730: 6447 1c00 7447 1c00 6c47 1c00 140a 0000 dG..tG..lG...... 01c4740: 6047 1c00 5847 1c00 6847 1c00 0000 0000 `G..XG..hG...... 01c4750: 0000 0000 0000 0000 ........ Surely, it's in the run-time memdump. Before recalculation: 90563020: 001C475C 001C4720 001C4770 000042E4 001C4764 001C4774 001C476C 00000A14 ^uart_base 90563040: 001C4760 001C4758 001C4768 00000000 00000000 00000000 EDFE0DD0 4C010000 After recalculation: 90563020: 905631AC 90563020 905631C0 903A2BE4 905631B4 905631C4 905631BC 9039F314 90563040: 905631B0 905631A8 905631B8 00000000 00000000 00000000 EDFE0DD0 4C010000 So it looks the non-static ('g') uninitialized variable sits in .bss sections well, while static ('l') one is not there. Is this expected? How the static one is being addressed? Or ask where the offset for static one is stored? Any info or comments are appreciated. -- Regards, Shawn

14 years, 6 months

3
9
0 0

[0/5] Improvements to vldN and vstN intrinsics

by Richard Sandiford

I've just submitted a merge request for the vldN and vstN intrinsic improvements. There are five related patches, so I thought it might be easier to review the merge if I posted the individual changes here. See: http://www.mail-archive.com/linaro-toolchain@lists.linaro.org/msg00969.html for an example of how this helps. Richard

14 years, 6 months

1
5
0 0

Test log comparison

by Michael Hope

I've fixed up the testcompare pages on ex.seabright.co.nz. It was getting confused by parallel testsuite runs and couldn't handle the results jumping about. I've also added a filter to buildlog that does a prefix match. Going to: http://ex.seabright.co.nz/helpers/buildlog/gcc-linaro shows just gcc-linaro results and: http://ex.seabright.co.nz/helpers/buildlog/gcc-linaro-4.5 for just 4.5 results. The bzr build results are looking good so far: armv7: http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.5+bzr99498/logs/… No changes except PCH. 99499 is still building. i686: http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.5+bzr99499/logs/… No changes. Note that the guality failures happen in 4.5.2 as well x86_64: http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.5+bzr99499/logs/… No changes. 4.6 related: x86_64: http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.6+bzr106734/logs… i686: http://ex.seabright.co.nz/helpers/testcompare/gcc-linaro-4.6+bzr106734/logs… armv7 is still building. -- Michael

14 years, 6 months

1
0
0 0

smc #0 unsuppored (bug 669912) gcc-4.5 linux-2.6.38

by AJ ONeal

I just did `git checkout` for linaro/linux-2.6.38 and tried compiling with CROSS_COMPILE=arm-linux-gnueabi- and I get this smc #0 error. The bug filed here is marked as fixed, but it's still broken for me: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/669912 I ran into this error once before, but I can't find my notes for it. I think the solution was to append something like $(sec) on a line in the Makefile. Any ideas? AJ ONeal

14 years, 6 months

3
2
0 0

Changing how we make changes

by Michael Hope

Hi there. I'd like to change and clarify how we make changes inside Linaro toolchain projects. The write-up is here: https://wiki.linaro.org/WorkingGroups/ToolChain/MakingChanges The short story is that now, just like mainline, the developers themselves do the final commit or merge into bzr. I've volunteered three of you on a review roster so that someone has the responsibility for reviewing patches each week. The roster is: * Ramana week 15, 17, 20, ... starting the 11th of April 2011 * Richard week 16, 18, 21, ... starting the 18th of April 2011 * Ulrich week 17, 19, 22, ... starting the 25th of April 2011 Anyone is welcome to review patches. The more eyes the better. Thoughts? -- Michael

14 years, 6 months

2
2
0 0

What is __aeabi_unwind_cpp_pr0?

by AJ ONeal

I'm just curious as to what "__aeabi_unwind_cpp_pr0" is or means. I can't find any explanation by googling. I'm about to post a separate e-mail with my problem concerning it. AJ ONeal

14 years, 6 months

1
0
0 0

[ACTIVITY] 11th -15th April

by Andrew Stubbs

Reviewed and approved Revital's do-loop patch, and Ira's store sinking patch. More precisely, I reviewed the test results from Michael's test system, and cast my eye over the patch to look for anything obvious. I don't pretend to know exactly what they do. Attended Ramana's thumb2 optimization discussion. Continued work on merging useful patches from CodeSourcery. Pushed the new patch set to Launchpad for testing in Michael's system. Pointed Bernd at lp:758082 - another probable shrink-wrap failure. Bernd responded with a new patch, and asked me to test it. I've pushed it to Launchpad and created a merge request. Posted an old patch of Dan's upstream: http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03144.html Pinged my thumb2 constants patch upstream. Richard E responded with some issues to address. I'll need to change the names of the constraints, at least. At Ramana's request, tested the NEON scheduling patch with SPEC2000. Encountered trouble with time-outs. Fixed those and retested. Posted an updated version of my EABI half-precision patch: http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03210.html Merged my backport of Julian's -fstrict-volatile-bitfields bug fix into Linaro GCC. The testing of the Android patches came back with a few test differences, but they appear to be unrelated to the patch, so are probably environmental. I've merged the changes to Linaro GCC. [Also spent most of Friday working on internal CS tasks.] ---- Upstream patched requiring review: * NEON scheduling patch http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html * NEON test cases http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03144.html * ARM EABI half-precision functions (reposted) http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03210.html

14 years, 6 months

1
0
0 0

[ACTIVITY] Apr.11 -- 17

by Chung-Lin Tang

== Last week == * CoreMark regressions: pushed a merge of my two upstream patches to Linaro 4.5, some current numbers are here: http://lists.linaro.org/pipermail/linaro-toolchain/2011-April/001087.html. * Continued working on another combine patch for improving CoreMark, hopefully ready to submit this week. * Committed fix for PR48325 (NEON POST_INC/PRE_DEC load/stores for struct modes) upstream. * Committed fix for PR48250 / Launchpad #723185 upstream. * Launchpad #689887, ICE in get_arm_condition_code(). My prior patch was tested to cause native bootstrap failure on Linaro 4.5, though retesting on upstream trunk worked fine. Still investigating. * Booked travel for Linaro-Budapest event. == This week == * Current combine patch. * Some unresolved patches, like PR46888. * Launchpad #689887, hope to figure this out.

14 years, 6 months

1
0
0 0

First session ideas for the summit

by Michael Hope

I've started up a page with ideas for sessions at next month's summit: https://wiki.linaro.org/MichaelHope/Sandbox/1111Blueprints They're a pretty direct map to the TSC technical topics so far which is nice to see. Feel free to add other ideas to the page. Each session is around 45 minutes, needs to be fairly well understood by the drafter beforehand, and should have concrete actions coming out of it. It's fine to have a few future/blue sky sessions but not too many. We'll discuss these at tonights meeting and assign drafters. -- Michael

14 years, 6 months

1
0
0 0

Some initial notes on the effects of vldN and vstN vectorisation

by Richard Sandiford

I've now submitted the initial vldN and vstN work, so I thought I'd see how often it triggers for natty's libav package. I've put some initial results here: https://wiki.linaro.org/RichardSandiford/Sandbox/NeonLibAv There are more files to go through, so this isn't complete. I've also left out cases that were very similar to the ones given. Some of the code is reasonable, while others are obviously not as good as they could be. I don't think the problems are really to do with the vldN and vstN work itself though. They seem to be due to the underlying interleaved load/store detection, or in the handling of widening operations. Richard

14 years, 6 months

2
1
0 0

[ACTIVITY] 2011-04-15

by David Gilbert

== Bug triaging == * Bug 745843 (vtk ftbfs) got it down to a bad arm/thumb transition - identified as a linker error and handed off to RichardS * Bug 758082 (augeas ftbfs) tracked it down to overwrite of a parameter in a variadic function before it got stacked; identified by Ramana as another instance of the shrink-wrap bug. * Bug 745861 (petsc ftbfs) isolated the collection of different mpi related problems this is hitting; really need to find an mpi expert on this * Bug 745863 & bug 745891 (ftbfs's) - both were compilations that timed out; verified this was due to using lots of RAM and also using lots of RAM on x86 (> ~500MB) - marked as invalid until the build farm grows more RAM * Bug 757427 gconf seg fault - failed to reproduce under various tests (although Michael has now managed to catch it in the act) == Optimisation == * neon memcpy tweeking; added prefetches and unrolled the core loop - now comparable perf to bionic memcpy in most cases (slower on misaligned destination, faster in other cases) * tweaked latrace to print address/length of argument strings so I can get some stats on routine usage. Dave

14 years, 6 months

1
0
0 0

[ACTIVITY] Weekly status

by Richard Sandiford

== This week == * Worked on a fix for https://bugs.launchpad.net/gcc-linaro/+bug/758082 Submitted the patch upstream. * Finished first cut of vldN and vstN vectorisation. Send the patches upstream. Most of the patches have been approved, but I'll wait for the others before committing. * Looked at how the vectoriser handles natty's libav. Found some nice loops, some OK-but-could-do-better, and some really atrocious. Wrote up the results here: https://wiki.linaro.org/RichardSandiford/Sandbox/NeonLibAv * Started writing micro benchmarks for each loop on that page. I'm about half way through now (starting from the bottom). * Started looking at whether the changes affect DENbench. * Patch review. * Wrote a small follow-up to the fix for LP 758082. * Some patch pinging. == Next week == * More micro benchmarks. * More DENbench. * Submit a merge request for the intrinsics improvements, if the remaining patches are approved. * Look at the poorer libav loops in more detail. Richard

14 years, 6 months

1
0
0 0

[ACTIVITY] report week 15

by Peter Maydell

RAG: Red: Amber: Green: now only 6 "core ARM emulation" patches in qemu-linaro not yet upstreamed (still lots of omap3 patches, though) Current Milestones: | Planned | Estimate | Actual | qemu-linaro 2011-04 | 2011-04-21 | 2011-04-21 | | Historical Milestones: finish qemu-cont-integration | 2011-01-25 | 2011-01-25 | handed off | first qemu-linaro release | 2011-02-08 | 2011-02-08 | 2011-02-08 | qemu-linaro 2011-03 | 2011-03-08 | 2011-03-08 | 2011-03-08 | == maintain-beagle-models == * some early prep for next week's qemu-linaro release == merge-correctness-fixes == * patch to fix Neon UNDEFs sent upstream and committed * patch fixing an overflow in signed VABAL.s32 upstreamed, committed * investigated a bug report which turns out to be that if you try to single step over an instruction which UNDEFs using qemu's gdb stub we execute the insn at the UNDEF vector and stop after it rather than stopping at the UNDEF vector * some investigation of qemu mishandling of FP exception flag setting; putting this on hold though, as it really isn't very high priority * reviewed patches from Aurelien doing some general softfloat cleanup == other == * trying to nail down proposed QEMU work for next cycle; work-in-progress: https://wiki.linaro.org/PeterMaydell/Qemu1111 * two IRC interviews for QEMU Google Summer of Code student to do some work on upstreaming of the Android emulator device models * meetings: toolchain, standup, architecture Q&A, divisional update Current qemu patch status is tracked here: https://wiki.linaro.org/PeterMaydell/QemuPatchStatus Absences: Holiday: 22 Apr - 2 May 9-13 May: UDS, Budapest (maybe) 15-16 August: QEMU/KVM strand at LinuxCon NA, Vancouver [LinuxCon proper follows on 17-19th]

14 years, 6 months

1
0
0 0

CoreMark Status

by Chung-Lin Tang

Hi, I've just pushed a merge of the current upstream patches for resolving the CoreMark regressions. (https://code.launchpad.net/~cltang/gcc-linaro/coremark-part1) To give a quick benchmark of the current status, testing Linaro 4.5 before/after the merge of those two patches: Optimization options used were just plain '-O2 -mtune=cortex-a9', tested on one of our Pandaboards running Maverick; all numbers are Iterations/Sec averaged from 3 runs. r99492 r9942+patches improve % -march=armv5te 2786.87 2848.12 2.20 % -march=armv7-a 2474.50 2775.92 12.18 % -march=armv7-a -mthumb 2297.86 2356.59 2.56 % I'll have to re-test to be sure, but the numbers/improvements obtained using upstream trunk should not be too far off, at least the ARM mode ones. As we discussed in prior meetings, there's still one point of regression identified that's in solving, which hopefully will finally bring the ARMv7-A numbers above ARMv5TE. Chung-Lin

14 years, 6 months

2
1
0 0

[Activity] 10th - 14th April

by Revital Eres

Hello, - Tracking down bugs exposed while testing a patch for SMS to avoid using -fauto-inc-dec flag and preparing fixes for them. Also, prepared a fix for PR47013. - Continue looking into DENbench and updating https://wiki.linaro.org/Internal/ToolChain/Benchmarks. Thanks, Revital

14 years, 6 months

1
0
0 0

[Activity] 11th - 14th April

by Ramana Radhakrishnan

== GCC == Progress: * Spent some time digging into binutils issue for Neon but still not sure why I see the problem when this is fixed in 2.21 branch and no one else see this. * Fixed PR 48090 upstream. * Some patch review. * T2 performance meeting. Plans when I'm back: * Continue looking at divmodsi4 improvements. * Continue looking at excessive VFP moves. * Backport the fix for the initialization of cgraph into FSF 4.5 branch. Meetings: * 1-1s * Linaro toolchain meeting * T2 performance. * Linaro@UDS meeting. Absences: * April 15 – 26 -> Booked. * May 9-14 - LDS Budapest

14 years, 6 months

1
0
0 0

Issue with noreturn static function with unused arg

by Loïc Minier

hey This problem with busybox: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621137 seems to be a toolchain issue. It occurs with FSF GCC 4.5.2 but not 4.6, and it doesn't occur with Linaro GCC 4.5 but it does with Debian gcc-4.5. I'm trying to identify the fix which Linaro applied to solve this! :-) Michael Hope told me he remembers we fixed something similar for Qt, but he couldn't find the patch and suggested I post here to get feedback. I've pushed ash.i and .s at: http://people.linaro.org/~lool/ash.i which you can build with: gcc -save-temps -std=gnu99 -Wall -Wshadow -Wwrite-strings -Wundef -Wstrict-prototypes -Wunused -Wunused-parameter -Wunused-function -Wunused-value -Wmissing-prototypes -Wmissing-declarations -Wdeclaration-after-statement -Wold-style-definition -fno-builtin-strlen -finline-limit=0 -fomit-frame-pointer -ffunction-sections -fdata-sections -fno-guess-branch-probability -funsigned-char -static-libgcc -falign-functions=1 -falign-jumps=1 -falign-labels=1 -falign-loops=1 -g -Os -c -o ash2.o ash.i the interesting part is that ash.s has tryexec as not returning, when it does return: grep ^tryexec ash.s -A5 | grep return this seems to be due to the combination of tryexec being static, its parent being noreturn, and one argument of tryexec being unused. Any idea of which Linaro patch solved this? :-) Does it make sense to raise this to FSF GCC 4.5? Thanks! -- Loïc Minier

14 years, 6 months

2
4
0 0

First toolchain estimate for the next cycle

by Michael Hope

Hi there. Mounir and I have been looking at the work for next cycle. A summary spreadsheet with notes is available here: https://spreadsheets0.google.com/ccc?key=ty1c-H56f0GxnL1Hk9LCmRg I'm very interested in feedback, especially on the time estimates and extra topics we should suggest to the TSC. See the notes at the top and feel free to add items or estimates straight into the sheet - anyone can view and anyone at Linaro should be able to edit. -- Michael

14 years, 6 months

2
2
0 0

Differences in build hosts

by Michael Hope

Hi there. I ran a build of gcc-linaro-4.5+bzr99491 on ursa1 through 4 to see if there was any difference in build machines. The following tests had different results: * gcc.c-torture/compile/limits-structnest.c * gcc.dg/graphite/block-4.c * largefile.c * obj-c++.dg/template-5.mm * obj-c++.dg/template-5.mm * obj-c++.dg/template-6.mm * obj-c++.dg/template-6.mm * objc/execute/class-4.m I suspect that they're all caused by running the testsuite in parallel and the host running out of memory. limits-structnest takes around 850 MB of RAM and passes on the machine with swap (ursa1) and fails on the others. block-4.c takes 2:35 to run and timed out on ursa1 and passed on the others which may be due to ursa1 swapping heavily while running a limit test in parallel. The obj-c tests show various forms of killed, and suggest that they were killed due to another process taking all the memory. I'll change the machines to use the full 1 G of memory, run the test suite in sequential mode, and see how things go. I haven't investigated largefile.c - it's a PCH test and these fail randomly. Regarding block-4.c, it takes 155 s to run which is too close to the default 300 s for my taste. Should we add a dg-timeout-factor 4.0 to it similar to block-3.c? -- Michael

14 years, 6 months

1
1
0 0

[Activity] April 4th - 8th

by Ramana Radhakrishnan

Missed sending this out earlier this week. == GCC == Progress: * Sync'd with Andrew about T2 performance stuff. * Spent some time investigating what could be done for divmodsi4 improvements . Working through the various phases. Not done tree level stuff for a while so my knowledge of the API is a a bit rusty. * Some upstream bugzilla duty. Plans: * Continue looking at divmodsi4 improvements. * Continue looking at excessive VFP moves. * Look at binutils + neon issue. * Performance kick-off meeting Meetings: * 1-1s * Linaro toolchain meeting * Andrew Stubbs meeting for 1 hour about T2 performance. Absences: * April 13th - Internal ARM conference. Not at desk all day. * April 15 – 26 -> Booked. * May 9-14 - LDS Budapest

14 years, 6 months

1
0
0 0

[ACTIVITY] weekly status

by Ken Werner

Hi, libunwind: * started to look on how to resume from a given stack frame: * other platforms use setcontext * setcontext is not implemented on ARM (glibc) * the *context functions have been marked obsolescent in Posix * http://pubs.opengroup.org/onlinepubs/009695399/functions/makecontext.html pandaboard: * gdb doesn't find separate debug info of libraries that have been put into a multiarch directory (#758619) Note: I'll be out of office to attend a class till (including) Friday. Regards Ken

14 years, 6 months

1
0
0 0

Today's T2 perf call.

by Ramana Radhakrishnan

A rough agenda for today's call. I'll put this on the wiki after the call. 1. Go over what we are all doing today - roughly Areas of investigation that we are looking at for near term. a. divmodsi4 work. b. Unnecessary VFP to integer register moves because of addressing modes availability. c. Thumb2 constants work d. Additional areas for headroom in DENBENCH. e. Coremark regressions fix up f. Revisions causing major regressions in coremark 2. Find a way of replicating the benchmarking results and make sure we get similar results to Michael and we are doing roughly the same thing. 3. Regular bi-weekly call following the Toolchain WG meeting ? Or do we organize another call ?

14 years, 6 months

2
1
0 0

[Bug 758082] [NEW] [armel] segfaults in make check pass when built with optimization

by Jani Monoses

Public bug reported: FTBFS on armel https://launchpadlibrarian.net/68239668/buildlog_ubuntu-natty-armel.augeas_… not apparent from the log but the failing of test-interpreter.sh is due to a core dump. Starting program: /home/jani/work/ftbfs/aug/augeas-0.8.0/src/.libs/lt- augparse --nostdinc -I . fail_let_no_exp.aug Program received signal SIGSEGV, Segmentation fault. strlen () at ../ports/sysdeps/arm/strlen.S:29 29 ../ports/sysdeps/arm/strlen.S: No such file or directory. in ../ports/sysdeps/arm/strlen.S (gdb) bt #0 strlen () at ../ports/sysdeps/arm/strlen.S:29 #1 0x4016c050 in _IO_vfprintf_internal (s=<value optimized out>, format=<value optimized out>, ap=<value optimized out>) at vfprintf.c:1620 #2 0x401d7b66 in __vasprintf_chk (result_ptr=0xbee5097c, flags=1, format=0x400d961c "%s", args=...) at vasprintf_chk.c:68 #3 0x400bfad6 in vasprintf (info=<value optimized out>, code=<value optimized out>, format=0x400d961c "%s", ap=...) at /usr/include/bits/stdio2.h:199 #4 format_error (info=<value optimized out>, code=<value optimized out>, format=0x400d961c "%s", ap=...) at syntax.c:96 #5 0x400bfd98 in syntax_error (info=0x1, format=0x400d961c "%s") at syntax.c:124 #6 0x400c3e96 in augl_error (locp=<value optimized out>, term=<value optimized out>, scanner=<value optimized out>, s=0x400d7abc "syntax error") at parser.y:628 #7 0x400c54f8 in augl_parse_file (aug=0x1ef1878, name=<value optimized out>, term=0xbee50a64) at parser.y:362 #8 0x400c153a in load_module_file (aug=0x1ef1878, filename=0xbee50ddb "fail_let_no_exp.aug") at syntax.c:1951 #9 0x400bbf0a in __aug_load_module_file (aug=0x1ef1878, filename=0xbee50ddb "fail_let_no_exp.aug") at augeas.c:1447 #10 0x00008b04 in main (argc=<value optimized out>, argv=0xbee50c84) at augparse.c:131 ** Affects: gcc-linaro Importance: Undecided Status: New ** Affects: augeas (Ubuntu) Importance: Undecided Status: New ** Tags: arm-porting-queue ** Also affects: gcc-linaro Importance: Undecided Status: New ** Summary changed: - segfaults in make check pass when built with optimization + [armel] segfaults in make check pass when built with optimization ** Tags added: arm-porting-queue -- You received this bug notification because you are a member of Linaro Toolchain Developers, which is subscribed to Linaro GCC. https://bugs.launchpad.net/bugs/758082 Title: [armel] segfaults in make check pass when built with optimization Status in Linaro GCC: New Status in “augeas” package in Ubuntu: New Bug description: FTBFS on armel https://launchpadlibrarian.net/68239668/buildlog_ubuntu-natty-armel.augeas_… not apparent from the log but the failing of test-interpreter.sh is due to a core dump. Starting program: /home/jani/work/ftbfs/aug/augeas-0.8.0/src/.libs/lt- augparse --nostdinc -I . fail_let_no_exp.aug Program received signal SIGSEGV, Segmentation fault. strlen () at ../ports/sysdeps/arm/strlen.S:29 29 ../ports/sysdeps/arm/strlen.S: No such file or directory. in ../ports/sysdeps/arm/strlen.S (gdb) bt #0 strlen () at ../ports/sysdeps/arm/strlen.S:29 #1 0x4016c050 in _IO_vfprintf_internal (s=<value optimized out>, format=<value optimized out>, ap=<value optimized out>) at vfprintf.c:1620 #2 0x401d7b66 in __vasprintf_chk (result_ptr=0xbee5097c, flags=1, format=0x400d961c "%s", args=...) at vasprintf_chk.c:68 #3 0x400bfad6 in vasprintf (info=<value optimized out>, code=<value optimized out>, format=0x400d961c "%s", ap=...) at /usr/include/bits/stdio2.h:199 #4 format_error (info=<value optimized out>, code=<value optimized out>, format=0x400d961c "%s", ap=...) at syntax.c:96 #5 0x400bfd98 in syntax_error (info=0x1, format=0x400d961c "%s") at syntax.c:124 #6 0x400c3e96 in augl_error (locp=<value optimized out>, term=<value optimized out>, scanner=<value optimized out>, s=0x400d7abc "syntax error") at parser.y:628 #7 0x400c54f8 in augl_parse_file (aug=0x1ef1878, name=<value optimized out>, term=0xbee50a64) at parser.y:362 #8 0x400c153a in load_module_file (aug=0x1ef1878, filename=0xbee50ddb "fail_let_no_exp.aug") at syntax.c:1951 #9 0x400bbf0a in __aug_load_module_file (aug=0x1ef1878, filename=0xbee50ddb "fail_let_no_exp.aug") at augeas.c:1447 #10 0x00008b04 in main (argc=<value optimized out>, argv=0xbee50c84) at augparse.c:131

14 years, 6 months

2
2
0 0

Conference code for today's Thumb-2 kick off call

by Michael Hope

Hi everyone. The conference code for today's call is 5238686884. The dial in numbers are the same as the weekly meeting. See: http://wiki.linaro.org/WorkingGroups/ToolChain/Meetings -- Michael

14 years, 6 months

1
0
0 0

[Bug 757427] [NEW] gconftool-2 segfaults on arm

by Jani Monoses

Public bug reported: The 2.32.2 upload of gconf is likely miscompiled and segfaults. This leads to other armel FTBFSs in the archive when calling gconftool-2 as part of the install phase. ** Affects: gcc-linaro Importance: Undecided Status: New ** Affects: gconf (Ubuntu) Importance: Undecided Status: New ** Tags: arm-porting-queue ** Package changed: ubuntu => gconf (Ubuntu) ** Also affects: gcc-linaro Importance: Undecided Status: New -- You received this bug notification because you are a member of Linaro Toolchain Developers, which is subscribed to Linaro GCC. https://bugs.launchpad.net/bugs/757427 Title: gconftool-2 segfaults on arm Status in Linaro GCC: New Status in “gconf” package in Ubuntu: New Bug description: The 2.32.2 upload of gconf is likely miscompiled and segfaults. This leads to other armel FTBFSs in the archive when calling gconftool-2 as part of the install phase.

14 years, 6 months

3
5
0 0

[ACTIVITY] Weekly status

by Richard Sandiford

== Last week == * Sent a fix for PR target/46329 upstream. * Discussed with Richard Guenther how to represent the interleaved load/store "functions" that we're adding to gimple. Sent a patch upstream for comments. Richard confirmed on IRC that he was happy with it, and no-one else has objected. * Spent most of the week on the vectorisation itself, and on the testsuite. == This week == * Finish work on vectorisation testsuite and submit. Richard

14 years, 6 months

1
0
0 0

[ACTIVITY] Apr.04 -- Apr.10

by Chung-Lin Tang

== Last week == * Mon/Tue (Apr.4--5): Tomb-sweeping Day, public holiday. * PR48250 / CS Issue #9845 / Launchpad #723185. Unaligned DImode reload under NEON. Worked on new patch, submitted to gcc-patches after testing on Friday. Awaiting review. == This week == * CoreMark ARMv6/v7 regressions: working on new combine patch.

14 years, 6 months

1
0
0 0

[ACTIVITY] 4th - 9th April

by Andrew Stubbs

The test results for the patch for lp:675347 on GCC 4.6 came back clean, so I merged it to Linaro GCC 4.6. The test results for lp:675347 on 4.5 had problems though, but they might be unrelated to the patch. The test results for the "discourage NEON on A8" patch had similar failures, and that's a 4.6 testsuite. Richard Earnshaw approved the Thumb register allocation patch. I've committed it upstream, and updated the patch trackers. It was already on the Linaro 4.6 branch. Now that GCC 4.6 is released, switched all the Linaro tracking tickets from 'Fix committed' to 'Fix released'. Merged from FSF 4.5 to Linaro 4.5 and submitted the patch for test. The tests came back clean, so I pushed it to the 4.5 branch. (Yay for Michael's new test service!) Merged more patches from SG++ to Linaro. Or, at least considered them for merge. Mostly I decided that they were not appropriate for Linaro, at least, not just yet. I have yet to push these patches to Launchpad. Reviewed Richard Sandiford's patch for LP:714921. Retried the Android build with a view to integrating Android support in Linaro GCC 4.5 (4.6 should already support it). Eventually, after downloading many different git repositories and branches, and maxing out the memory on my machine a few times, I managed a successful build using the toolchain the Android team are using. I then backported Maxim's patches to Linaro GCC 4.5, and built and tested that, and got another successful Android build. I've pushed the patched toolchain to Launchpad at lp:~ams-codesourcery/gcc-linaro/android for testing. All being well, I'll merge Android support into the 4.5 trunk in time for the next release. ---- Upstream patched requiring review: * Thumb2 constants: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html * ARM EABI half-precision functions http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00874.html * NEON scheduling patch http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html

14 years, 6 months

2
1
0 0

[ACTIVITY] 2011-04-08

by David Gilbert

- Back from holiday, short week. == Porting jam == * We seem to have picked up a lot of ftbfs in the last couple of weeks - which is unfortunate because it may well be too close to the Natty release to do anything about them * Bug 745843 is a repeatable segfault in part of the build process of a package called vtk that is used by a few other things ; I've got this down to a particular call of one function - although gdb is getting rather confused (r0 & r1 changing as I single step across a branch) * Bug 745861 petsc build failure; I'm getting one of two different link errors depending which mood it is in - mpi related? * Bug 745873 - a meta package that just didn't have a list of packages to build with for armel; easy to do a simple fix (provided branch that built) for but the maintainer says it's too late for natty anyway and some more thought is needed. == Other == * Reading over some optimisation documents * Tested weekly release on Beagle-c4 (still no OTG usb and hence no networking for me) * Also simple boot test on panda; not much time for more thorough test. (seems to work) Dave

14 years, 6 months

1
0
0 0

[ACTIVITY] weekly status

by Ken Werner

Hi, == libunwind == * created a generic and local variant of the extbl parser * continued to look into testsuite failures * down to 12 failures: https://wiki.linaro.org/KenWerner/Sandbox/libunwind * continue to post patches upsteam Note: I'll be out of office to attend a class starting from Wednesday till Friday next week. Regards Ken

14 years, 6 months

1
0
0 0

[ACTIVITY] report week 14

by Peter Maydell

RAG: Red: Amber: Green: Current Milestones: | Planned | Estimate | Actual | qemu-linaro 2011-04 | 2011-04-21 | 2011-04-21 | | Historical Milestones: finish qemu-cont-integration | 2011-01-25 | 2011-01-25 | handed off | first qemu-linaro release | 2011-02-08 | 2011-02-08 | 2011-02-08 | qemu-linaro 2011-03 | 2011-03-08 | 2011-03-08 | 2011-03-08 | == maintain-beagle-models == * I spent a couple of days on initial cleanup of the omap3 patchstack in qemu-linaro. It's still some way from being upstreamable but at least now every patch in the stack compiles; this should make rebasing on upstream a bit less painful. * the board-ram-limits patchset is still stalled with upstream :-( == merge-correctness-fixes == * Aurelien applied lots of patches so the pipeline has drained again * cleaning up/reworking patches which fix handling of Neon UNDEF cases. Not very exciting but it will get a large set of patches out of the qemu-linaro patchstack. == other == * meetings: toolchain, standup Current qemu patch status is tracked here: https://wiki.linaro.org/PeterMaydell/QemuPatchStatus Absences: Holiday: 22 Apr - 2 May 9-13 May: UDS, Budapest (maybe) 15-16 August: QEMU/KVM strand at LinuxCon NA, Vancouver [LinuxCon proper follows on 17-19th]

14 years, 6 months

1
0
0 0

[Merge] lp:~rsandifo/gcc-linaro/lp-714921-4.5 into lp:gcc-linaro

by noreply＠launchpad.net

The proposal to merge lp:~rsandifo/gcc-linaro/lp-714921-4.5 into lp:gcc-linaro has been updated. Status: Needs review => Merged For more details, see: https://code.launchpad.net/~rsandifo/gcc-linaro/lp-714921-4.5/+merge/56525 -- https://code.launchpad.net/~rsandifo/gcc-linaro/lp-714921-4.5/+merge/56525 Your team Linaro Toolchain Developers is subscribed to branch lp:gcc-linaro.

14 years, 6 months

1
0
0 0

Launchpad: Validate your team's contact email address

by Launchpad Email Validator

Hello The Launchpad user named 'Michael Hope (michaelh1)' requested the registration of 'linaro-toolchain(a)lists.linaro.org' as the contact email address of team 'Linaro Toolchain Developers'. This request can only be made by a team owner/administrator, so if this change request was unexpected or was not requested by one of the team's administrators, please contact system-error(a)launchpad.net. If you want to make this email address the contact email of 'Linaro Toolchain Developers', please click on the link below and follow the instructions. https://launchpad.net/token/6sQQKQ6kx3XP9MlWMwmX Thanks, The Launchpad Team

14 years, 6 months

1
0
0 0

New porter boxes

by Michael Hope

Hi there. The new porter boxes are now available for use. See: https://wiki.linaro.org/WorkingGroups/ToolChain/Hardware for details. These are PandaBoards with 768 MB of memory, a USB HDD, and a good internet connection. They can be used for day to day jobs like building programs, triaging bugs, and running benchmarks. Use dchroot natty to switch into the chroot. Use sudo apt-get install yyy to install packages. The build dependences for GCC, GDB, and binutils should already be installed. -- Michael

14 years, 6 months

1
0
0 0

[ACTIVITY] April 3-7

by Ira Rosen

Hi, * continued bringing patches upstream - changing default vector size to 128 - resubmitted with changes according to comments, awaiting review - if-conversion improvement - committed * PR 48252 - bug in vzip/vuzp/vtrn implementation - patch submitted * opened PR 48454 - a test failure with -mvectorize-with-neon-quad Next week - vacation. April 18-27 - Passover Holiday, I'll only work half days on April 18 and April 24. And possibly half days on April 20 and 21. Ira

14 years, 6 months

1
0
0 0

Tegra2 errata bug

by David Gilbert

https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/739374 is the bug relating to the Tegra errata mentioned today. Dave

14 years, 6 months

1
0
0 0

[ACTIVITY] Apr 04 - Apr 06

by Ulrich Weigand

== GDB == * Ongoing work to fix single-stepping over signal handlers (bug #615978). * Posted patch to support NEON registers in core files (bug #615972). * Failure to disable address space randomization (bug #616001) is shown to be a kernel problem; created stand-alone test case and opened bug against kernel team. == Schedule == * On vacation 04/07 - 04/15. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

14 years, 7 months

1
0
0 0

Re: Linaro 4.5.2 v. CodeSourcery 4.5.1

by Andrew Stubbs

On 25/03/11 21:48, Diane Holt wrote: > I hope you don't mind me sending you mail, but I'm a bit stuck...I've > been told I need the Linaro 4.5.2 toolchain because it has some "neon > optimizations" that the CS 4.5.1 doesn't have. In general, you'd be better addressing these questions on the Linaro Toolchain mailing list: linaro-toolchain(a)lists.linaro.org (I've copied it in). Not least because I'm on vacation for the next week. :) > Unfortunately, the Linaro > 4.5.2 that's available for download (already built) won't work in my > Scratchbox environment, since it was compiled against a glibc that's too > new. The CS 4.5.1 works fine -- but I'm not allowed to use it, because > of the neon stuff. The CS and Linaro compilers are really very similar, but CodeSourcery has not made a release since the autumn, so Linaro will have some extra features. > Do you know whether CS actually does have (or will have) the same neon > optimizations Linaro has? It depends which optimizations you are referring to? The existing CS release had the latest improvements at the time it was released, and I believe that the upcoming release will probably be very similar to Linaro (at least, with respect to ARMv7 - there'll be many differences for other architecture variants), but I'm not promising that. Sorry if that's a bit vague, but I the contents of the next CS release is still not finalised. > If it doesn't (and won't), then I'm going to have to build the Linaro > one from source. Unfortunately, I've not been able to find any detailed > information on how to go about doing that. Do you know if that's > documented anywhere? Are you talking about building native compiler, or a cross-compiler? The former is very simple (provided you have all the dependencies), while the latter is more involved. Here's the recipe to build a native compiler: tar xf gcc-linaro.....tar.bz2 mkdir objdir cd objdir ../gcc-linaro....../configure --prefix=<your-install-path> <opts> make bootstrap make install You can copy the configure <opts> from another compiler using 'gcc -v' and './configure --help' in the source tree should tell you what they mean. If you want to build a cross compiler, I suggest you look at crosstool or crosstool-ng, or OpenEmbedded. Building cross-toolchains is non-trivial. Hope that helps. Andrew

14 years, 7 months

5
15
0 0

CoreMark over releases

by Michael Hope

Here's some pretty pictures of the relative CoreMark performance on a Cortex-A9. Note that in accordance with the CoreMark rules, all results are estimates. Linaro GCC 4.5 and mainline GCC vs 4.5.2: http://people.linaro.org/~michaelh/incoming/all-o3-vs-gcc-4.5.2.png Linaro GCC 4.5 releases vs our first: http://people.linaro.org/~michaelh/incoming/releases-o3-vs-gcc-linaro-4.5-2… Linaro GCC 4.5 builds between 2010.08 and 2010.10: http://people.linaro.org/~michaelh/incoming/releases-o3-vs-gcc-linaro-4.5-2… The 2.5 % drop in performance for 2010.09 is probably due to r99379. The further 2 % drop in 2010.10 is due to re-syncing with mainline 4.5.2. Performance has been moving solidly upwards but it has to start from the -4.5 % from these two updates. Chung Lin's unsigned extension changes should be interesting... -- Michael

14 years, 7 months

2
2
0 0

Linaro toolchain integration with ChromiumOS build

by PANKAJ KUMAR DUBEY

14 years, 7 months

2
1
0 0

[ACTIVITY] Weekly status

by Richard Sandiford

== Last week == * Finished the patch that I was working on last week to use memory operands rather than register operands in neon.md. Submitted upstream: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01996.html Among other things, this allows the intrinsics to use post-modified addresses. * Submitted patches to make the number of rtl generator arguments (as opposed to insn operands) available to the expand-time code: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02227.html http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02228.html http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02229.html This is part of the tree-rtl expansion "cleanups" that I've been doing in preparation for the vectoriser work. * More discussion about the handling of type modes vs. per-function target switching. I've think we've agreed what the right approach is, although it's probably outside the scope of this project. The discussion was still useful because it meant I could submit & defend the next patch. * Submitted a patch to use non-BLK modes for arrays of vectors (like uint32x2x2_t & co. in arm_neon.h); http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02192.html This avoids that stack spilling that was discussed during the week. Richard Guenther seemed happy with the patch in principle, but understandably wanted to see how the optabs stuff worked out first. Also, the testcase he asked me to try exposed another instance of: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46329 so that needs to be fixed first. * Started writing & testing a fix for that PR (46329). == This week == * Finish fix for PR46329. * More vld & vst stuff. Richard

14 years, 7 months

1
0
0 0

[ACTIVITY] Mar.28 -- Apr.03

by Chung-Lin Tang

== Last week == * PR48250 / CS Issue #9845 / Launchpad #723185. Unaligned DImode reload under NEON. Went back and forth with Richard Earnshaw on gcc-patches for most of the week. The issues should finally be clear, and I think it would be better to modify the significant parts of arm_legitimize_reload_address() to do the right thing rather than just fixing the bug. I have a new patch done over the weekend, though it still shows a few regressions after some testing. I hope this gets done by this week... * PR48325 / Launchpad #744754, another NEON ICE in postreload. This appears to be the IA/DB modes for VLDM/VSTM for NEON struct modes were not enabled. This ICE actually does not happen currently on upstream trunk, but sent patch anyways. Pending review. * Spent some time on Launchpad #736661 (C++ ICE in expr.c), and looked at upstream testsuite regressions of gcc.dg/pr17957.c and gcc.dg/torture/pr47975.c under -mfpu=neon (ICE on OImode const0_rtx assignment). * Call with Ramana on ARM optimization work. == This week == * Get PR48250/Launchpad #723185 nailed. * Other pending GCC issues. * TW Public Holiday, Mon. and Tue. (Apr.4-5)

14 years, 7 months

1
0
0 0

Improvements to bzr

by Michael Hope

The Bazaar team have been working on improving the performance of bzr on the gcc-linaro tree. Here's how long the steps take on my machine with the current 2.4 development version: Update tip before branching: bzr pull 20.4 s (no revisions) Make the branch: bzr branch --hardlink 4.5 optspace 26.8 s Do some work and commit it: ...change two files bzr status 1:05 (again) bzr status 1.7 s bzr commit . 3.6 s Push the changes up: bzr push lp:~michaelh1/gcc-linaro/optspace 3:47 ~9 MB (~40 kB/s which is saturating my uplink) Later, the merge master pulls the branch down and merges: bzr branch --no-tree lp:~michaelh1/gcc-linaro/optspace 36 s ~900 k bzr merge ../optspace 3:26 The bzr status and bzr commit are quite good. I've asked them to look into bzr merge. -- Michael

14 years, 7 months

1
0
0 0

can linaro toolchain compile ARM earlier than Cortex A8?

by Barry Song

Hi All, After downloading linaro toolchain by apt-get in ubuntu, I compiled the uboot for ARM1136 SoC with -march=armv5 option. And it can compile successfully. Then I let the uboot run on target boards and system failed due to "undefined instructions". Checked linaro toolchain options, it is: #arm-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=arm-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.5.2/lto-wrapper Target: arm-linux-gnueabi Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.2-5ubuntu2~ppa1' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.5.2 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --program-prefix=arm-linux-gnueabi- --includedir=/usr/arm-linux-gnueabi/include --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabi --with-headers=/usr/arm-linux-gnueabi/include --with-libs=/usr/arm-linux-gnueabi/lib Thread model: posix gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-5ubuntu2~ppa1) The imporant options are "--with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16". I just want to ask whether these options stop arm-linux-gnueabi-gcc to support old arch? If so, according to gcc documents at http://gcc.gnu.org/install/configure.html, " --with-cpu=cpu --with-cpu-32=cpu --with-cpu-64=cpu Specify which cpu variant the compiler should generate code for by default. cpu will be used as the default value of the -mcpu= switch. This option is only supported on some targets, including ARM, i386, M68k, PowerPC, and SPARC. The --with-cpu-32 and --with-cpu-64 options specify separate default CPUs for 32-bit and 64-bit modes; these options are only supported for i386, x86-64 and PowerPC. --with-schedule=cpu --with-arch=cpu --with-arch-32=cpu --with-arch-64=cpu --with-tune=cpu --with-tune-32=cpu --with-tune-64=cpu --with-abi=abi --with-fpu=type --with-float=type These configure options provide default values for the -mschedule=, -march=, -mtune=, -mabi=, and -mfpu= options and for -mhard-float or -msoft-float. As with --with-cpu, which switches will be accepted and acceptable values of the arguments depend on the target. " There are only default values for later compiling. Users should be able to swith to other values by setting other options. But why did arm-linux-gnueabi-gcc still build "undefined instructions" to arm1136 with "arch=armv5"? In fact arm1136 is armv6. Then i compiled a toolchain for linaro gcc-linaro-4.4-2011.02-0 codes by myself, the options are simple: #arm-none-linux-gnueabi-gcc -v Using built-in specs. Target: arm-none-linux-gnueabi Configured with: ../gcc-linaro-4.4-2011.02-0/configure --target=arm-none-linux-gnueabi --prefix=/home/vmuser/development/toolchain/build-toolchain/tools --enable-languages=c,c++ --disable-libgomp Thread model: posix gcc version 4.4.5 (Linaro GCC 4.4-2011.02-0) Then I compiled uboot by this toolchain again, the uboot can work. Then why can the toolchain compiled by myself support more arch? And what performance is lost in my compiling? Thanks Barry

14 years, 7 months

4
10
0 0

[Activity] March 28 - April 1

by Ramana Radhakrishnan

== GCC == Progress: * Investigated excessive VFP moves . Partially investigating ways forward. * Polished up my divmodsi4 patch. Discussed it during the call. Looking for ways to do it properly at the tree level. * Got Panda board on Friday. * Off on Wednesday. * Conversations with Revital and Chung-Lin. Need to sync up with Andrew next week. * Found an issue with binutils and Neon and this is now LP:747837 Plans: * Continue looking at excessive VFP moves. * Finish working through Thumb2 speed tickets. * Set up new Panda board. * Conversation with Andrew sometime this week. Meetings: * 1-1s * Linaro toolchain meeting Absences: * April 15 – 26 -> Booked Holiday. * May 9-14 - LDS Budapest

14 years, 7 months

1
0
0 0

[ACTIVITY] Mar 28 - Apr 01

by Ulrich Weigand

== GDB == * Committed patch to fix single-stepping across bad ARM/Thumb boundary (bug #667309) to mainline and Linaro GDB. * Committed patch to fix accessing "fpscr" register to mainline. * Ongoing work to fix single-stepping over signal handlers (bug #615978). Posted yet another updated patch to gdb-patches for comments. * Implemented patch to support NEON registers in core files (bug #615972). * Investigated failure to disable address space randomization (bug #616001). Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

14 years, 7 months

1
0
0 0

[ACTIVITY] weekly status

by Ken Werner

Hi, == pandaboard == * noticed that hw perf events are not working on 2.6.38-1001-linaro-omap * it seems that the omap kernel has not configured its PMU properly * perf_event_open syscall returns ENODEV * started discussion with agreen (#744458) * noticed that natty puts its glibc into a multilib path * prevents linaro gcc (and upstream) from being built == libunwind == * created a generic and local variant of the extbl parser * ran the test suite a few times using different unwind methods * started to look into the test suite failures * started to fix a couple of the failures on ARM Regards Ken

14 years, 7 months

1
0
0 0

[ACTIVITY] report week 13

by Peter Maydell

RAG: Red: Amber: Green: the aircon has been fixed; blessed quiet again Current Milestones: | Planned | Estimate | Actual | qemu-linaro 2011-04 | 2011-04-21 | 2011-04-21 | | Historical Milestones: finish qemu-cont-integration | 2011-01-25 | 2011-01-25 | handed off | first qemu-linaro release | 2011-02-08 | 2011-02-08 | 2011-02-08 | qemu-linaro 2011-03 | 2011-03-08 | 2011-03-08 | 2011-03-08 | == maintain-beagle-models == * the board-ram-limits patchset has been expanded significantly to address upstream suggestions; it now includes a lot of refactoring of sun4m (sparc) board code to use the new generic max-ram functionality instead of a sun4m-specific bit of code. Unfortunately there is still some pushback upstream on the grounds that a simple max-ram limit doesn't cater for complicated NUMA situations :-( == merge-correctness-fixes == * working on moving implementation of VLD/VST "multiple structures" forms into qemu helper functions; the current implementation is correct but can expand to hundreds of TCG ops which is well beyond the maximum permitted value, so could potentially overrun a TCG buffer == other == * wrote up some technical/engineering input into what we ought to be doing with qemu next cycle * review of a patch by Dmitry Eremin-Solenikov adding ARMv4/v4T support * some review of s390 TCG patches (not because we have a direct interest in s390 but as part of being a good citizen upstream) * sent a pull request for some neon patches that had been on the list a few weeks; hopefully this will help drain the patch pipeline * meetings: toolchain, standup, pdsw-tools Current qemu patch status is tracked here: https://wiki.linaro.org/PeterMaydell/QemuPatchStatus Absences: Holiday: 22 Apr - 2 May 9-13 May: UDS, Budapest (maybe) ~17-19 August: QEMU/KVM strand at LinuxCon NA, Vancouver

14 years, 7 months

1
0
0 0

[ACTIVITY] March 27-31

by Revital Eres

Hello, * Submitted merge requests for SMS patch to gcc-linaro and gcc-linaro/4.6. * Testing SMS patch which extends the current implementation to consider loops that contain instructions with REG_INC_NOTE. * Filed PRs 48336 48380 for recent fails of trunk on ARM. * Had a chat with Ramana about the DENbench benchmarks, directions and findings. * Filed PR 745743 in linaro gcc-bugzilla Thanks, Revital

14 years, 7 months

1
0
0 0

[ACTIVITY] March 27-31

by Ira Rosen

Hi, * continued bringing patches upstream - auto-detection of vector size - committed - changing default vector size to 128 - submitted and testing the final version - if-conversion improvement - submitted and now testing the final version * gcc-linaro-4.6 - submitted a merge request for store sink patch (this patch is already upstream) Ira

14 years, 7 months

1
0
0 0

Stand up call

by Michael Hope

Hi there. Just a reminder that the standup call is now at 0900 UTC on Thursdays. The first is in about half an hour. -- Michael

14 years, 7 months

1
0
0 0

NEON intrinsics and stack access

by Michael Hope

For reference. We know that the NEON intrinsics in GCC have issues. I came across this page: http://hilbert-space.de/?p=22 which has a colour to greyscale conversion done using intrinsics. gcc-linaro-4.5-2011.03-0 does poorly through saving intermediate values on the stack. The core of the loop is: .L3: mov ip, r4 vld3.8 {d16-d18}, [r6] vstmia r4, {d16-d18} ldmia ip!, {r0, r1, r2, r3} mov sl, r9 adds r7, r7, #1 adds r6, r6, #24 stmia sl!, {r0, r1, r2, r3} fldd d16, [sp, #24] fldd d18, [sp, #32] ldmia ip, {r0, r1} vmull.u8 q8, d16, d19 stmia sl, {r0, r1} vmlal.u8 q8, d18, d20 fldd d18, [sp, #40] vmlal.u8 q8, d18, d21 vshrn.i16 d16, q8, #8 vst1.8 {d16}, [r5] adds r5, r5, #8 cmp r8, r7 bgt .L3 llvm-2.9~svn128540 does much better: vld3.8 {d20, d21, d22}, [r1]! add r3, r3, #1 cmp r3, r2 vmull.u8 q12, d21, d16 vmlal.u8 q12, d20, d17 vmlal.u8 q12, d22, d18 vshrn.i16 d19, q12, #8 vst1.8 {d19}, [r0]! blt .LBB0_1 and may actually be better than the had-written assembler on Nils's page due to scheduling the loop comparison earlier. Richard S, were you looking into this? -- Michael

14 years, 7 months

2
1
0 0

Feature branch for var-tracking OOM

by Richard Sandiford

I've put the 4.5 version of the var-tracking OOM patch here: lp:~rsandifo/gcc-linaro/lp-714921-4.5 Richard

14 years, 7 months

1
0
0 0

Toolchain today

by Michael Hope

Hi there. A reminder that today's call has shifted due to the European daylight savings change. It's now at 0800 UTC which is 9 am in the UK, 10 am in central Europe, and 10 am in Israel. -- Michael

14 years, 7 months

1
0
0 0

[ACTIVITY] Mar.21 -- Mar.27

by Chung-Lin Tang

== Last week == * PR46934: Thumb-1 ICE, small fix in the "casesi" jump-table expand code. Quickly approved and committed upstream. * Enhance XOR patch for gcc/simplify-rtx.c. Updated comments and committed upstream. * PR48250 / CS Issue #9845 / Launchpad #723185. Unaligned DImode reload under NEON. Submitted patch upstream, but still need to do some more verification that older pre-ARMv5TE cases are safe. Should complete this week. * Working on a type of ICE seen currently on upstream trunk, a few testcases failing under '-O3 -g'. It seems VTA related, but also might have something to do with register elimination not fully done for (var_location (entry_value ...)) expressions, leaving [afp+#num] memory addresses existing in debug insns after reload. Still investigating. * Launchpad #689887, ICE in get_arm_condition_code(). Pushed a merge request to Linaro 4.5 for this patch. Also another LP#742961 appeared as another case of this ICE... * Still working on (what I think should be) the last of the CoreMark ARMv6 regressions. The problem is to combine uxtb+cmp into ands #255. This could be done by adding (set (cc) (compare (zero_extend...))) patterns, implemented by ands assembly, but still looking if this can be done (probably more elegantly) by something like CANONICALIZE_COMPARISON (replacing compare operands) in the ARM backend. * Launchpad #736007, ICE immed_double_const under -mfpu=neon -g. Some discussion on gcc-patches about this, still unclear on what should be done... == This week == * Push forward on above issues.

14 years, 7 months

1
0
0 0

[ACTIVITY] 21st - 26th March

by Andrew Stubbs

Committed Dan's RVCT interoperation patch, both upstream and to Linaro GCC 4.6. Adjusted Benrd's "Discourage NEON on Cortex-A8" patch following Richard Earnshaw's comments, and reposted upstream. The new version was approved, and committed. I've also submitted a merge proposal to Linaro GCC 4.6. Dropped Tom's patch for marking smalls strings read-only. This optimization seems to have no visible effect for ARM in GCC 4.6. I'll leave it it to Tom to forward-port, if it's still meaningful for MIPS. Julian has committed the patch for lp:675347, so I've submitted merge requests to both Linaro GCC 4.5 and 4.6. Bernd has posted the shrink wrapping patches upstream. I've posted this info in all the relevant Linaro tracking tickets. Talked Revital Eres through the Bazaar/Launchpad merge request system. Tried to understand why GCC 4.6 does not use multiply-and-accumulate efficiently, when used with 64-bit values. It seems that the compiler sometimes uses (subreg:SI (reg:DI ...)) and sometimes just uses a plain (reg:SI ..) and those don't combine to give useful patterns, but I haven't got to the bottom of it yet. Tested an FSF GCC 4.6 snapshot from the 23rd. All well, so I've merged it to the Linaro GCC 4.6 branch. * Future Absence Away Monday 28th to Friday 1st April. ---- Upstream patched requiring review: * Thumb2 constants: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html * ARM EABI half-precision functions http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00874.html * ARM Thumb2 Spill Likely tweak http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00880.html * NEON scheduling patch http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html

14 years, 7 months

1
0
0 0

[ACTIVITY] weekly status

by Ken Werner

Hi, == libunwind == * modified the extbtl-parser to operate on the DWARF model directly * this adds support for unwinding call stacks with mixed (DWARF and extbl) frames on ARM * did a few other fixes and cleanups * posted the patches on the libunwind ml * set up a tree on git.linaro.org * attended a class on friday Regards Ken

14 years, 7 months

1
0
0 0

[ACTIVITY] Mar 21 - Mar 25

by Ulrich Weigand

== GDB == * Completed glibc patch to add ARM unwind tables to system call stubs (bug #684218), patch committed upstream and backported to Ubuntu glibc. * Posted kernel patch to fixes GDB inferior calls while stopped in a restartable system call (bug #615974); waiting for review. * Ongoing work to fix single-stepping over signal handlers (bug #615978). * Implemented patch to fix single-stepping across bad ARM/Thumb boundary (bug #667309); posted to mailing list for comments. * Contributed two fixes for valgrind on ARM (to enable running GDB under valgrind); both now accepted mainline. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

14 years, 7 months

1
0
0 0

[ACTIVITY] Weekly status

by Richard Sandiford

== This week == * Moved the discussion about the RTL and gimple representation of strided loads/stores to the gcc@ list. Got some good feedback: http://gcc.gnu.org/ml/gcc/2011-03/msg00322.html * Started a subdiscussion about the handling of modes: http://gcc.gnu.org/ml/gcc/2011-03/msg00342.html This is a tricky one. I'll add more fuel to the fire next week. * Committed two GCC patches to clean up the expand interface. Dealt with the fallout (some expected, but unfortunately some not). * Submitted two of the patches to improve code generation for strided load/store intrinsics: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01631.html http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01634.html * Spent a lot of the week reworking the way the load/store intrinsics are handled, to fix both correctness and performance bugs. The new rtl patterns should have the right form for the vectoriser. Made what feels like good progress, but it's not complete yet. * Sent separate R_ARM_IRELATIVE patch to glibc, after feedback from glibc-ports. * Booked flight and hotel for Budapest summit. * Pinged unreviewed patches. == Next week == * More intrinsics improvements. I think these are necessary to get good code out of the vectoriser too. Richard

14 years, 7 months

1
0
0 0

[ACTIVITY] 2011-03-25

by David Gilbert

== String routines == * Wrote a thumb optimised strchr - As expected it's got nice performance for longer runs but at sizes <16 bytes it's slower, and a lot of the strchr calls are very short, so it's probably not of benefit in most cases ( https://wiki.linaro.org/WorkingGroups/ToolChain/Benchmarks/InitialStrchr?ac… ) * Wrote a neon-memcpy - As previously found with memset, it performs well on A8 but poorly on A9 - it does however do the case where the source/destination isn't aligned quite well even on A9 ; the vld1 unaligned case works with relatively little penalty. (it performs comparably to the Bionic implementation - mine is a bit faster on shorter calls, Bionic is better on longer uses - I think that's because they've got some careful use of preloads where I have so far got none). I'm on holiday up to and including 5th April. Dave

14 years, 7 months

1
0
0 0

[Activity] March 21-25

by Ramana Radhakrishnan

== GCC == Progress: * Investigated excessive VFP moves . Investigating ways forward. * Went through some of the test results with 4.6 RC2 upstream - looking through test results etc. * Setup SPEC2k6 cross on my Linaro machine. * Waiting for my new Panda board sometime next week. * Some small bug fixes upstream. Need to rework a couple of documentation patches after review. Plans: * Continue looking at excessive VFP moves. * Continue to look at some patches upstream. * Finish working through Thumb2 speed tickets. * Set up new Panda board. * Start looking at DENBench results and identify potential speed up areas. Meetings: * 1-1s * Linaro toolchain meeting Absences: * March 30th (maybe): WC Cricket Semi-final. (Ind v Pak) * April 15 – 26 -> Booked Holiday. * May 9-14 - LDS Budapest

14 years, 7 months

1
0
0 0

[ACTIVITY] report week 12

by Peter Maydell

RAG: Red: Amber: Green: Current Milestones: | Planned | Estimate | Actual | qemu-linaro 2011-04 | 2011-04-21 | 2011-04-21 | | Historical Milestones: finish qemu-cont-integration | 2011-01-25 | 2011-01-25 | handed off | first qemu-linaro release | 2011-02-08 | 2011-02-08 | 2011-02-08 | qemu-linaro 2011-03 | 2011-03-08 | 2011-03-08 | 2011-03-08 | == maintain-beagle-models == * benchmarking/testing of the TCG locking fix: oddly benchmarks seem to come out with less slowdown (1% or less) than a system mode bootup/shutdown. (I used scimark and dhrystone. scimark is the same speed, which is to be expected because we spend all our time doing floating point emulation. I was expecting a bigger perf hit on dhrystone, though.) * submitted patches to make qemu fail cleanly if you ask for more RAM than a board supports == merge-correctness-fixes == * tested the Neon element load/store instructions; wrote patches to fix UNDEF handling (which are blocked waiting for the patch pipeline to be drained) and confirmed there aren't any other bugs. There is a meego patch to use helper functions for multi-element load/store which is apparently to avoid overflowing a TCG buffer: need to test and upstream this. * investigated android qemu tree for any missing correctness fixes: looking through the changelog I think we have fixes upstream for everything that was fixed in the android tree. == other == * patch: fix versatilepb/realview handling of multiple nic options * patch: better diagnosis of more nics requested than board supports [this is needed to get the vexpress patch committed] * reviewed a patch to add ARMv4/v4T support to qemu (mostly consists of making sure we UNDEF in the right places) * meetings: toolchain, standup, pdsw-tools, 1-2-1 Current qemu patch status is tracked here: https://wiki.linaro.org/PeterMaydell/QemuPatchStatus Absences: Holiday: 22 Apr - 2 May 9-13 May: UDS, Budapest (maybe) ~17-19 August: QEMU/KVM strand at LinuxCon NA, Vancouver

14 years, 7 months

1
0
0 0

[ACTIVITY] March 20-24

by Revital Eres

Hello, Implemented a patch to apply SMS in the presence of instructions with REG_INC_NOTE. (this occurs in telecom/autocor thus SMS needs to be run with -fno-auto-inc-dec flag to be applied) Sent a merge request to gcc-linaro for the SMS patches. Thanks to Andrew Stubbs for his help. https://code.launchpad.net/~eres/gcc-linaro/SMS_doloop_for_ARM I intend to send a request to gcc-linaro.4.6 as well. Thanks, Revital

14 years, 7 months

1
0
0 0

[ACTIVITY] March 22-24

by Ira Rosen

Hi, * resubmitted and committed store sink patch to trunk, I'll commit it to gcc-linaro-4.6 next week * submitted autodetection of vector size patch to gcc-patches, I'l commit it next week * started testing a patch that makes mvectorize-with-neon-quad the default * DenBench: found some more cases where vectorization of strided accesses using vzip/vuzp causes degradation. Since Richard is making a lot of progress with vlsd/vst, I think it doesn't make sense to spend too much time on vzip/vuzp, and I am going to run DenBench without this patch. Ira

14 years, 7 months

1
0
0 0

Re: Cross compiler ITP (armel)

by Goswin von Brederlow

Philipp Kern <trash(a)philkern.de> writes: > On 2011-03-23, Goswin von Brederlow <goswin-v-b(a)web.de> wrote: >> Also does the testing transition consider the Built-Using? If I specify >> 'Built-Using: gcc-4.5 (= 4.5.2-5)' will the package be blocked from >> entering testing until gcc-4.5 (= 4.5.2-5) has entered and block gcc-4.5 >> (= 4.5.2-5) from being replaced from testing? > > It doesn't need to. All we want is compliance on the archive side so that the > sources are not expired away, as long as that binary is carried in a suite. > No need to involve britney at that point. > > Kind regards > Philipp Kern Not quite. For ia32-libs it would be nice if ia32-libs could be blocked from testing as long as the source packages it includes aren't in testing. Currently that is solved by building against testing in the first palce. But that is something we can live with. As a side note the debian-cd package needs to also consider Built-Using when creating source images. Will the Sources.gz file list multiple entries for a source if multiple versions are relevant? MfG Goswin

14 years, 7 months

2
1
0 0

Re: Cross compiler ITP (armel)

by Hector Oron

Hi, 2009/11/2 Mark Hymers <mhy(a)debian.org>: > On Mon, 02, Nov, 2009 at 12:43:42PM +0000, Philipp Kern spoke thus.. >> Of course it is a sane approach but very special care needs to be taken when >> releasing to ensure GPL compliance. So what we should get is support in the >> toolchain to declare against what source package the upload was built to >> keep that around. > We haven't implemented that yet for the archive software but it's on the > TODO list (and not that difficult). None of us have had time to do the > d-d-a post from the ftpteam meeting yet, but I'll make sure information > is in there about it. > > I'm hoping to the archive-side support done in the next week or so. Squeeze has already been released, cross toolchains were not released along Debian main, but found at Emdebian repository. Marcin Juszkiewicz has been working out cross compiler packages for armel as part of his work for Linaro, which I attempt to include into Debian main archive. As a result of the work done, linux-armel, binutils-armel, eglibc-armel are merged into a single source package named `cross-toolchain-base', the package is not optimal, but once we got multiarch support, it should be renamed to `binutils-armel' (or similar name) and use linux and eglibc libraries and headers provided by multiarch. Along this package I also plan to upload `gcc-4.5-cross' (#590465). At the moment we are targeting one target architecture on two build hosts ('{amd64,i386}->armel'), not sure if it is desired to be supported on more build hosts. Target architecture support might grow up in future, but right now it is not a priority. Not sure if that is an issue for someone? Comments? Best regards, -- Héctor Orón "Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us." -- Day DVB-T stop working nicely Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html

14 years, 7 months

8
12
0 0

[ACTIVITY] Weekly status

by Richard Sandiford

== Last week == * Committed STT_GNU_IFUNC changes to binutils. * Submitted the STT_GNU_IFUNC changes to GLIBC ports. Got feedback on Friday, which I'll deal with this week. * Worked on the expand and rtl-level parts of the load/store lane representation, with new optabs for each operation. This seems to be working pretty well, but I still need to make some changes to the way the existing intrinsics work. * Wrote a patch to clean up the way we handle optabs during expand, so that the new optabs mentioned above will need a bit less cut-&-paste. Submitted upstream. Got some positive feedback. * Committed testcase for PR rtl-optimization/47166 upstream. == This week == * Deal with GLIBC feedback. * More load/store lanes. Richard

14 years, 7 months

1
0
0 0

[ACTIVITY] 21st - 25th March

by Andrew Stubbs

* Linaro GCC Tested and merged both the latest Linaro merge requests, and various bug fixes to the Shrink Wrap optimization from CS, into Linaro GCC 4.5. Merged and tested from FSF GCC 4.6. Richard and Ramana have approved some of my upstream patches! I just need to wait for stage one so I can commit them upstream. I'll commit them internally when I get time to do the final integration test. Continued benchmarking GCC 4.6 with the patches merged from GCC 4.5. Decided to discard a couple of extra patches since they don't appear to be of any value. * Other On leave Wednesday to Friday playing daddy. :) * Future Absence Away Monday 28th to Friday 1st April. ---- Upstream patched requiring review: * Thumb2 constants: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html * ARM EABI half-precision functions http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00874.html * ARM Thumb2 Spill Likely tweak http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00880.html * NEON scheduling patch http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html

14 years, 7 months

1
1
0 0

Substituting -msoft-float/-mfloat-abi=* in the proper order in spec file

by Loïc Minier

Hey I'm trying to extend the *link: specs to pass a different -dynamic-linker depending on the float ABI. But I didn't manage to build a construct which would preserve the order of the flags; if I do something like: %{msoft-float:-dynamic-linker V1} %{mfloat-abi=softfp:-dynamic-linker V2} Then I get V2 for "-mfloat-abi=softfp -msoft-float" instead of V1. In gcc/gcc.c I found some docs on spec file syntax; I see one can use %{S*&T*} and %{S*:X}, but apparently %{S*&T*:X} isn't allowed, so I can't manipulate the value. I tried to use %{msoft-float*:-dynamic-linker V1} %{mfloat-abi=softfp*:-dynamic-linker V2} but that gives the same effect (the msoft-float flags are grouped together in the original order and put first, then the mfloat-abi=softfp are grouped together in the original order and put second). I didn't manage to get %{msoft-float*:%<msoft-float -dynamic-linker V1} to work; in fact I didn't get supressions to work. Any idea? Thanks! PS: float-abit=softfp/soft-float are just convenient examples; the actual target is to use different -dynamic-linker for hard vs soft float-abi -- Loïc Minier

14 years, 7 months

2
1
0 0

Trip Report -- 1st QEMU Users Forum, Grenoble, 18 March 2011

by Peter Maydell

I went to the first QEMU Users Forum in Grenoble last week; this is my impressions and summary of what happened. Sorry if it's a bit TLDR... == Summary and general observations == This was a day long set of talks tacked onto the end of the DATE conference. There were about 40 attendees; the focus of the talks was mostly industrial and academic research QEMU users/hackers (a set of people who use and modify QEMU but who aren't very well represented on the qemu-devel list). A lot of the talks related to SystemC; at the moment people are rolling their own SystemC<->QEMU bridges. In addition to the usual problems when you try to put two simulation engines together (each of which thinks it should be in control of the world) QEMU doesn't make this easy because it is not very modular and makes the assumption that only one QEMU exists in a process (lots of global variables, no locking, etc). There was a general perception from attendees that QEMU "development community" is biased towards KVM rather than TCG. I tend to agree with this, but think this is simply because (a) that's where the bulk of the contributors are and (b) people doing TCG related work don't always appear on the mailing list. (The "quick throwaway prototype" approach often used for research doesn't really mesh well with upstream's desire for solid long-term maintainable code, I guess.) QEMU could certainly be made more convenient for this group of users: greater modularisation and provision of "just the instruction set simulator" as a pluggable library, for instance. Also the work by STMicroelectronics on tracing/instrumentation plugins looks like it should be useful to reduce the need to hack extra instrumentation directly into QEMU's frontends. People generally seemed to think the forum was useful, but it hasn't been decided yet whether to repeat it next year, or perhaps to have some sort of joint event with the open-source qemu community. More detailed notes on each of the talks are below; the proceedings/slides should also appear at http://adt.cs.upb.de/quf within a few weeks. Of particular Linaro/ARM interest are: * the STMicroelectronics plugin framework so your DLL can get callbacks on interesting events and/or insert tracing or instrumentation into generated code * Nokia's work on getting useful timing/power type estimates out of QEMU by measuring key events (insn exec, cache miss, TLB miss, etc) and calibrating against real hardware to see how to weight these * a talk on parallelising QEMU, ie "multicore on multicore" * speeding up Neon by adding SIMD IR ops and translating to SSE The forum started with a brief introduction by the organiser, followed by an informal Q&A session with Nathan Froyd from CodeSourcery (...since his laptop with his presentation slides had died on the journey over from the US...) == Talk 1: QEMU and SystemC == M. Monton from GreenSocs presented a couple of approaches to using QEMU with SystemC. "QEMU-SC" is for systems which are mostly QEMU based with one or two SystemC devices -- QEMU is the master. Speed penalty is 8-14% over implementing the device natively. "QBox" makes the SystemC simulation the master, and QEMU is implemented as a TLM2 Initiator; this works for systems which are almost all SystemC and which you just want to add a QEMU core to. Speed penalty 100% (!) although they suspect this is an artifact of the current implementation and could be reduced to more like 25-30%. They'd like to see a unified effort to do SystemC and QEMU integration (you'll note that there are several talks here where the presenters had rolled their own integration). Source available from www.greensocs.com. == Talk 2: Combined Use of Dynamic Binary Translation and SystemC for Fast and Accurate MPSoc Simulation == Description of a system where QEMU is used as the core model in a SystemC simulation of a multiprocessor ARM system. The SystemC side includes models of caches, write buffers and so on; this looked like quite a low level detailed (high overhead) simulation. They simulate multiple clusters of multiple cores, which is tricky with QEMU because it has a design assumption of only one QEMU per process address space (lots of global variables, no locking, etc); they handle this by saving and restoring globals at SystemC synchronisation points, which sounded rather hacky to me. They get timing information out of their model by annotating the TCG intermediate representation ops with new ops indicating number of cycles used, whether to check for Icache/Dcache hit/miss, and so on. Clearly they've put a lot of work into this. They'd like a standalone, reentrant ISS, basically so it's easier to plug into other frameworks like SystemC. == Talk 3: QEMU/SystemC Cosimulation at Different Abstraction Levels == This talk was about modelling an RTOS in SystemC; I have to say I didn't really understand the motivation for doing this. Rather than running an RTOS under emulation, they have a SystemC component which provides the scheduler/mutex type APIs an RTOS would, and then model RTOS tasks as other SystemC components. Some of these SystemC components embed user-mode QEMU, so you can have a combination of native and target-binare RTOS tasks. They're estimating time usage by annotating QEMU translation blocks (but not doing any accounting for cache effects). == Talk 4: Timing Aspects in QEMU/SystemC Synchronisation == Slightly academic-feeling talk about how to handle the problem of trying to run several separate simulations in parallel and keep their timing in sync. (In particular, QEMU and a SystemC world.) If you just alternate running each simulation there is no problem but it's not making best use of the host CPU. If you run them in parallel you can have the problem that sim A wants to send an event to sim B at time T, but sim B has already run past time T. He described a couple of possible approaches, but they were all "if you do this you might still hit the problem but there's a tunable parameter to reduce the probability of something going wrong"; also they only actually implemented the simplest one. In some sense this is really all workarounds for the fact that SystemC is being retrofitted/bolted onto the outside of a QEMU simulation. == Talk 5: Program Instrumentation with QEMU == Presentation by STMicroelectronics, about work they'd done adding instrumentation to QEMU so you can use it for execution trace generation, performance analysis, and profiling-driven optimisation when compiling. It's basically a plugin architecture so you can register hooks to be called at various interesting points (eg every time a TB is executed); there are also translation time hooks so plugins can insert extra code into the IR stream. Because it works at the IR level it's CPU-agnostic. They've used this to do real work like optimising/debugging of the Adobe Flash JIT for ARM. They're hoping to be able to submit this upstream. I liked this; I think it's a reasonably maintainable approach, and it ought to alleviate the need for hacking extra ops directly into QEMU for instrumentation (which is the approach you see in some of the other presentations). In particular it ought to work well with the Nokia work described in the next talk... == Talk 6: Using QEMU in Timing Estimation for Mobile Software Development == Work by Nokia's research division and Aalto university. This was about getting useful timing estimates out of a QEMU model by adding some instrumentation (instructions executed, cache misses, etc) and then calibrating against real hardware to identify what weightings to apply to each of these (weightings differ for different cores/devices; eg on A8 your estimates are very poor if you don't account for L2 cache misses, but for some other cores TLB misses are more important and adding L2 cache miss instrumentation gives only a small improvement in accuracy.) The cache model is not a proper functional cache model, it's just enough to be able to give cache hit/miss stats. They reckon that three or four key statistics (cache miss, TLB miss, a basic classification of insns into slow or fast) give estimated execution times with about 10% level of inaccuracy; the claim was that this is "feasible for practical usage". Git tree available. This would be useful in conjunction with the STMicroelectronics instrumentation plugin work; alternatively it might be interesting to do this as a Valgrind plugin, since Valgrind has much more mature support for arbitrary plugins. (Of course as a Valgrind plugin you'd be restricted to running on an ARM host, and you're only measuring one process, not whole-system effects.) == Talk 7: QEMU in Digital Preservation Strategies == A less technical talk from a researcher who's working on the problems of how museums should deal with preserving and conserving "digital artifacts" (OSes, applications, games). There are a lot of reasons why "just run natively" becomes infeasible: media decay, the connector conspiracy, old and dying hardware, APIs and environments becoming unsupported, proprietary file formats and on and on. If you emulate hardware (with QEMU) then you only have to deal with emulating a few (tens of) hardware platforms, rather than hundreds of operating systems or thousands of file formats, so it's the most practical approach. They're working on web interfaces for non-technical users. Most interesting for the QEMU dev community is that they're effectively building up a large set of regression tests (ie images of old OSes and applications) which they are going to be able to run automatic testing on. == Talk 8: MARSS-x86: QEMU-based Micro-Architectural and Systems Simulator for x86 Multicore Processors == This is about using QEMU for microarchitectural level modelling (branch predictor, load/store unit, etc); their target audience is academic researchers. There's an existing x86 pipeline level simulator (PLTsim) but it has problems: it uses Xen for its system simulation so it's hard to get installed (need a custom kernel on the host!), and it doesn't cope with multicore. So they've basically taken PLTsim's pipeline model and ported it into the QEMU system emulation environment. When enabled it replaces the TCG dynamic translation implementation; since the core state is stored in the same structures it is possible to "fast forward" a simulation running under TCG and then switch to "full microarchitecture simulation" for the interesting parts of a benchmark. They get 200-400KIPS. == Talk 9: Showing and Debugging Haiku with QEMU == Haiku is an x86 OS inspired by BeOS. The speaker talked about how they use QEMU for demos and also for kernel and bootloader debugging. == Talk 10: PQEMU : A parallel system emulator based on QEMU == This was a group from a Taiwan university who were essentially claiming to have solved the "multicore on multicore" problem, so you can run a simulated MPx4 ARM core on a quad-core x86 box and have it actually use all the cores. They had some benchmarking graphs which indicated that you do indeed get ~3.x times speedup over emulated single-core, ie your scaling gain isn't swamped in locking overhead. However, the presentation concentrated on the locking required for code generation (which is in my opinion the easy part) and I wasn't really convinced that they'd actually solved all the hard problems in getting the whole system to be multithreaded. ("It only crashes once every hundred runs...") Also their work is based on QEMU 0.12, which is now quite old. We should definitely have a look at the source which they hope to make available in a few months. == Talk 11: PRoot: A Step Forward for QEMU User-Mode == STMicroelectronics again, presenting an alternative to the usual "chroot plus binfmt_misc" approach for running target binaries seamlessly under qemu's linux-user mode. It's a wrapper around qemu which uses ptrace to intercept the syscalls qemu makes to the host; in particular it can add the target-directory prefix to all filesystem access syscalls, and can turn an attempt to exec "/bin/ls" into an exec of "qemu-linux-arm /bin/ls". The advantage over chroot is that it's more flexible and doesn't need root access to set up. They didn't give figures for how much overhead the syscall interception adds, though. == Talk 12: QEMU TCG Enhancements for Speeding up Emulation of SIMD == Simple idea -- make emulation of Neon instructions faster by adding some new SIMD IR ops and then implementing them with SSE instructions in the x86 backend. Some basic benchmarking shows that they can be ten times faster this way. Issues: * what is the best set of "generic" SIMD ops to add to the QEMU IR? * is making Neon faster the best use of resource for speeding up QEMU overall, or should we be looking at parallelism or other problems first? * are there nasty edge cases (flags, corner case input values etc) which would be a pain to handle? Interesting, though, and I think it takes the right general approach (ie not horrifically Neon specific). My feeling is that for this to go upstream it would need uses in two different QEMU front ends (to demonstrate that the ops are generic) and implementations in at least the x86 backend, plus fallback code so backends need not implement the ops; that's a fair bit of work beyond what they've currently implemented. == Talk 13: A SysML-based Framework with QEMU-SystemC Code Generation == This was the last talk, and the speaker ran through it very fast as we were running out of time. They have a code generator for taking a UML description of a device and turning it into SystemC (for VHDL) and C++ (for a QEMU device) and then cosimulating them for verification. -- PMM

14 years, 7 months

1
0
0 0

Evaluate Link Time Optimization (LTO) in linaro-gcc 4.5

by Jim Huang

Hello list, Recently, Android team is working on integrating Linaro toolchain for Android and NDK. According to the initial benchmark results[1], Linaro GCC is competitive comparing to Google toolchain. In the meanwhile, we are trying to enable gcc-4.5 specific features such as Graphite and LTO (Link Time Optimization) in order to make the best choice for Android build system and NDK usage. However, I encountered a problem about LTO and would like to ask help from toolchain WG. Assuming Linaro Toolchain for Android is installed in directory /tmp/android-toolchain-eabi, you can obtain Google's toolchain benchmark suite by git: # git clone git://android.git.kernel.org/toolchain/benchmark.git You have to apply the attached patch in order to make benchmark suite work[2]. Then, change directory to skia: # cd benchmark/skia And build skia bench with LTO enabled: # ../scripts/bench.py --action=build --toolchain=/tmp/android-toolchain-eabi --add_cflags="-flto -user-linker-plugin" The build process would be interrupted by gcc: make -j4 --warn-undefined-variables -f ../scripts/build/main.mk TOOLCHAIN=/tmp/android-toolchain-eabi ADD_CFLAGS="-flto -user-linker-plugin" build CPP ARM obj/src/core/Sk64.o <= src/src/core/Sk64.cpp CPP ARM obj/src/core/SkAlphaRuns.o <= src/src/core/SkAlphaRuns.cpp CPP ARM obj/src/core/SkBitmap.o <= src/src/core/SkBitmap.cpp CPP ARM obj/src/core/SkBitmapProcShader.o <= src/src/core/SkBitmapProcShader.cpp CPP ARM obj/src/core/SkBitmapProcState.o <= src/src/core/SkBitmapProcState.cpp CPP ARM obj/src/core/SkBitmapProcState_matrixProcs.o <= src/src/core/SkBitmapProcState_matrixProcs.cpp src/src/core/SkBitmapProcShader.cpp: In function 'SkShader::CreateBitmapShader(SkBitmap const&, SkShader::TileMode, SkShader::TileMode, void*, unsigned int)': src/src/core/SkBitmapProcShader.cpp:243:13: warning: 'color' may be used uninitialized in this function CPP ARM obj/src/core/SkBitmapSampler.o <= src/src/core/SkBitmapSampler.cpp src/src/core/SkBitmapProcState_matrixProcs.cpp:530:1: sorry, unimplemented: gimple bytecode streams do not support machine specific builtin functions on this target ... However, I can get other bench items passed such as cximage, gcstone, gnugo, mpeg4, webkit, and python. Can anyone give me some hints to resolve LTO problem? Thanks in advance. Sincerely, -jserv [1] https://wiki.linaro.org/Platform/Android/Toolchain#Reference%20Benchmark We use the same toolchain benchmark suite as Google compiler team took. [2] https://wiki.linaro.org/Platform/Android/UpstreamToolchain

14 years, 7 months

3
3
0 0

[ACTIVITY] Mar.14 -- Mar.20

by Chung-Lin Tang

== Last week == * CoreMark ARMv6/v7 regressions: posted another combine patch upstream, which was quickly approved and committed. The XOR simplification one is now approved too, but needs a little more revising of comments before committing. * The above two patches now bring CoreMark under -march=armv7-a to very close of the performance of -march=armv5te. However, a regression where uxtb+cmp cannot be combined into 'ands ... #255' still causes v7 to lose slightly. This should be the final issue to solve... * Launchpad #736007/GCC Bugzilla PR48183: NEON ICE in emit-rtl.c:immed_double_const() under -g. Posted patch upstream, but looks like more discussion is needed before we know if this is the "right" way to do it. * Launchpad #736661, armel FTBFS (G++ ICE in expand_expr_real_1()). Looking at this. * Pinged a few upstream patch submissions. == This week == * Launchpad #723185/CS issue #9845 now assigned to me, start looking at this. * Get the XOR patch committed upstream, and the above described uxtb+cmp issue solved. * Work on other GCC issues.

14 years, 7 months

1
0
0 0

Tracking tickets as they go by

by Michael Hope

Hi there. I have a custom report on top of the Launchpad tickets that shows how old they are and if they need attention: http://ex.seabright.co.nz/helpers/tickets/gcc-linaro?group_by=lint I check this once a day to see how we're doing. It's useful when deciding which bug to attack next. -- Michael

14 years, 7 months

1
0
0 0

[ACTIVITY] weekly status

by Ken Werner

== libunwind == * Had few discussions with Uli with regard to unwinding. * Continued to learn about libunwind internals. * The .ARM.exidx and .ARM.extbl section parser is functional but the integration into libunwind needs to be improved. Currently there are two seperate models that hold the informations of the current frame. Since they are not synchronized the behavior of libunwind is quite unexpected to the user. * I started on eliminating the redundancy by removing the model that was introduced for the extbl support. My goal is to have the parser operate on the DWARF model directly. In theory this should also allow to mix DWARF- and extable-frames. Regards Ken

14 years, 7 months

1
0
0 0

[Activity] March 7 - 18

by Ramana Radhakrishnan

== GCC == * Started looking at performance regressions. Setting up builds with EEMBC Denbench and other benchmarks. * Looked at PR47719 in some detail this week. * Set up environment on laptop . Fixed PR46788 in 4.6 branch and trunk. * Discussions regarding armhf, how to maintain Linaro branches - upstreaming patches etc. * Looked at a case of performance improvements with VFP stores. I think it's because we end up allowing PRE_INC and POST_DEC for floating point mode values because of which there end up being more transfers to and from the integer core registers. * Off sick on Monday 14th March 2011. == Misc == * Sorted out travel arrangements for LDS. Waiting for visa now.

14 years, 7 months

1
0
0 0

[ACTIVITY] Mar 14 - Mar 18

by Ulrich Weigand

== GDB == * Ongoing work on glibc patch to add ARM unwind tables to system call stubs (bug #684218). * Implemented initial version of a kernel patch that fixes GDB inferior calls while stopped in a restartable system call (bug #615974); started discussion with kernel folks. * Implemented new version of patch to fix single-stepping over signal handlers (bug #615978) that addresses review comments; posted to mailing list. * Verified Linaro GDB patch set can be applied to Ubuntu package. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

14 years, 7 months

1
0
0 0

[ACTIVITY] report week 11

by Peter Maydell

(sent early this week since I'll be in the conference all Friday) RAG: Red: Amber: Green: Current Milestones: | Planned | Estimate | Actual | Historical Milestones: [trimmed the 2010 ones] finish qemu-cont-integration | 2011-01-25 | 2011-01-25 | handed off | first qemu-linaro release | 2011-02-08 | 2011-02-08 | 2011-02-08 | qemu-linaro 2011-03 | 2011-03-08 | 2011-03-08 | 2011-03-08 | == maintain-beagle-models == * wrote most of a patch to properly implement prlimit64 syscall in usermode -- needs checking/testing * wrote most of a patch to allow boards to specify their min/max/default RAM size rather than having a single qemu-wide default; this would let us specify RAM size on the beagle model (currently hardwired) * retested the patch I wrote late last year which fixes TCG's locking problems by having interrupting signals/threads just set a flag which we check in every TB (rather than trying to mess with the TCG graph in a totally unsafe and crashprone way). Slowdown: about 3.5% on "boot Linaro nano on vexpress to rootprompt and shutdown again". I shall see if I can persuade people that this is a price worth paying for not randomly crashing in thread-heavy code :-) == merge-correctness-fixes == * Wrote/submitted patchset which fixes VRECPS edge case handling (mostly NaN related) * Wrote/submitted patchset which fixes Neon VLD of single element to all lanes * Wrote/submitted patch which fixes qemu to work on an ARM host where the host C code has been built in Thumb mode == other == * attended QEMU Users Forum in Grenoble * meetings: toolchain, standup, pdsw-tools, arch q&a Current qemu patch status is tracked here: https://wiki.linaro.org/PeterMaydell/QemuPatchStatus Absences: 17/18 March: QEMU Users Forum, Grenoble Holiday: 22 Apr - 2 May 9-13 May: UDS, Budapest (maybe) ~17-19 August: QEMU/KVM strand at LinuxCon NA, Vancouver

14 years, 7 months

1
0
0 0

[ACTIVITY] 2011-03-17

by David Gilbert

Short week * libffi patch accepted upstream * eglibc integration of string routine changes - I have something that works but it's more complex than I'd like (to get it to fall back to the C code on stuff I haven't optimised for). * Trying a neon memchr; tried a really simple 8 byte a loop version - it's quite slow on both A8 and A9; branching on the result of comparisons done in the neon is not simple. * Porting jam bug 735877 chromium using d32 float; it was passing vpfpv3 rather than using the default when configured without neon. On holiday tomorrow (Friday). Dave

14 years, 7 months

1
0
0 0

[ACTIVITY] March 13-17

by Revital1 Eres

Hello, Experiment with aes benchmark from DENbench. Continue my experiments with SMS which includes re-implementing an old patch to insert reg-moves in free slots rather than greedily before the definition as is done in the current implementation. Thanks, Revital

14 years, 7 months

1
0
0 0

[ACTIVITY] March 13-17

by Ira Rosen

Hi, * submitted store sinking patch to mainline * started testing auto-detection of vector size patch * DENBench - some benchmarks are still unstable, I am looking into stable regressions, adjusting and fixing the cost model for them Next week: Sunday and Monday - holidays Ira

14 years, 7 months

1
0
0 0

Versatile Express write-up

by Michael Hope

Here's a end-of-cycle write up for Versatile Express support in QEMU: https://wiki.linaro.org/WorkingGroups/ToolChain/Outputs/QEMUVersatileExpress Most of it is taken from Peter's page: https://wiki.linaro.org/PeterMaydell/QemuVersatileExpress which is the place to go if you want the current state and more detail on the steps involved. While writing this up I had a seamless experience from the first linaro-image-create until seeing the alpha3 greeter come up and wobbling the mouse around. It was awesome. Some ideas for other write-ups at: https://wiki.linaro.org/WorkingGroups/ToolChain/Outputs -- Michael

14 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain