Hi!
I need a little help with triaging of this bug, it is a little different
from the ones I have triaged so far:
https://bugs.launchpad.net/launchpad/+bug/945503 - gcc-4.7 branch imports
fail (timeouts)
It is already set to Confirmed, my question is what is needed to go to the
triaged stage?
Also, the comments from wgrant and jelmer somewhat indicates that there is
no problem.
Best regards
Åsa
Hello,
since this long-standing problem just hit me again, I had a quick look at
test failures in our farm that appear to occur whenever the directory name
contains a string that is being checked for via a "scan-assembler" test,
e.g.:
+FAIL: gcc.target/arm/sat-1.c scan-assembler-times ssat 4
+FAIL: gcc.target/arm/sat-1.c scan-assembler-times usat 4
I had been assuming this happens because the directory name somehow finds
its name into the assembler file, e.g. via a .file directive or DWARF data,
and therefore an additional instance of the search string is being detected
erroneously.
However, when I attemted to re-create the scenario by building myself
within a directory that has the same name, but on my local machine, the
tests when through fine. And indeed, inspecting the assembler source shows
that that there is no debug info at all; while there is a .file directive,
it contains just the file base name without any directory name; and in fact
the directory name does not show up at all within the assembler file.
Something must still be different in the runs that take place on the build
farm; but I currently do not understand what that might be.
Michael, is there a way to interact with the build process on the build
farm machines themselves to try and find out what's going on here?
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
Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
Hi toolchain folks,
I have a problem with U-boot compiled for an ARMv4 system (Integrator)
using Linaro 2012.02-20120222, it just crashes. Compiling the same
U-Boot with CodeSourcery 2010-q1 works fine.
Symptom:
Resetting CPU ...
undefined instruction
pc : [<07fdecd4>] lr : [<07fdeb34>]
sp : 07f91380 ip : 00000000 fp : 00000001
r10: 010258fc r9 : 00000000 r8 : 07f94f64
r7 : 07f94eb0 r6 : 00989680 r5 : 000186a0 r4 : 000186a0
r3 : 000003e8 r2 : 000f423f r1 : 000f4240 r0 : 05f5e100
Flags: nzCv IRQs on FIQs on Mode SVC_32
(repeated ad nauseam)
The only hint I have is the constant 000186a0, which appears
here in the put_dec() routine from U-boots vsprintf(), which is
nothing special, it's Douglas Jones' binary to decimal conversion
code from the Linux kernel, but the compiles objects DOES
contain calls to __aeabi_uidivmod, __udivsi3, __div64_32.
Do we know of any potential trouble in these helpers on ARMv4?
The file containing these functions is compiled like this:
arm-linux-gnueabi-gcc -M -g -Os -fno-common -ffixed-r8 -msoft-float
-D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x01000000
-I/var/linus/u-boot/build-integrator/include2
-I/var/linus/u-boot/build-integrator/include
-I/var/linus/u-boot/include -fno-builtin -ffreestanding -nostdinc
-isystem /home/linus/src/gcc-linaro-arm-linux-gnueabi-2012.02-20120222_linux/bin/../lib/gcc/arm-linux-gnueabi/4.6.3/include
-pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux
-mno-thumb-interwork -march=armv4 -MQ
/var/linus/u-boot/build-integrator/lib/vsprintf.o vsprintf.c
>/var/linus/u-boot/build-integrator/lib/.depend.vsprintf
Yours,
Linus Walleij
Hi,
GDB on Android:
* Spent some time understanding the intricate build process used
to compile NDK's gdbserver.
* After a lot of tinkering and trial and error I was finally able
to produce a gdbserver binary which when running on the Android
emulator and talking to a GDB (also compiled by me) on the host
is able to show all threads and provide a useful backtrace.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
Hi there. When you do a commit that fixes a bug, try adding a
'--fixes lp:123456' to the bzr commit. Launchpad recognises these and
automatically link the branch and merge request to the bug report.
This makes it easier for the reporter to see progress. If you forget
to update the bug status (such as bumping it from 'Triaged' to 'In
progress') then it's obvious that it's being worked on.
See https://bugs.launchpad.net/gcc-linaro/+bug/942307 for an example.
The status was 'Triaged' but there's an approved merge request which
shows work is being done.
-- Michael
Merged FSF GCC 4.7 to the Linaro GCC 4.7 branch.
Merged from GCC 4.6.3 release to Linaro GCC 4.6 branch.
Wrote and posted a patch to load DImode immediate constant into NEON
registers properly. Unfortunately, testing showed a bootstrap stage 2
vs. 3 miscompare, so there's something not quite right. However,
disassembly of the binaries hasn't revealed any problems, so this
failure is still a mystery. More investigation required.
Wrote and posted a patch to do DImode negation in NEON. Realised that I
had forgotten to do the core-register fall-back case; posted a new
version. Again, there's something annoyingly subtle that prevents
bootstrap. This time it looks like some sort of wrong code bug.
Investigating.
Wrote and posted a patch to do DImode one's complement in NEON. Richard
E questioned how it was written though. The tests passed successfully,
so that's a novelty this week!
Looked for other NEON instructions missing support. Didn't find any ...
but the machine description isn't exactly straight forward.
Considered the problems with choosing whether or not to do an operation
in NEON, or not. Discussed the existing state and possible solutions
with Ramana and Benrd (thanks Guys). Thought about it some more. Posted
a vague description of what might fix it to the linaro-toolchain list.
Awaiting replies.
Hi!
* Development benchmarks:
Finished the first implementation, sent to Michael for review.
* This became a very short week because of sickness.
Plans for week 10 is to triage existing bugs, and to get going again with
the SunSpider benchmark.
Regards
Åsa
Summary:
* Multilib on linaro toolchain.
Details:
1. Multilib test for linaro toolchain.
* Fix the multilib build issue when multiarch patch is applied.
* Fix a bug in crosstool-ng upstream to build multilib for glibc/eglibc.
* Successfully build multilib toolchain for armv6t2, cortex-a8 and
cortex-a9. And tests show it can link the correct libraries.
2. Still issues:
* Multilib and multiarch uses different directory structures.
Multilib build can not find the correct directories in the prebuilt
oneiric-sysroot.
* Build armv5t arm mode lib when default mode is thumb for armv7-a.
Annual leaves:
* Mar. 1-2.
Plans:
* Finalize the multilib solution for linaro binary toolchain.
* Work on code size optimization for the embedded toolchain.
Best regards!
-Zhenqiang
