Hello,
My name is Jiandong Zheng and am working on a few ARM specific projects.
I have been using Linaro toolchain coming with Ubuntu to do Cortext-A9
building. I also need to maintain code for old ARM11 SoC so that Linaro
toolchain is my preference and it did the job well back in Maverick days
if I remember correctly.
However, in Precise, I have troubles running this ARM11 u-boot and
kernel built with Linaro toolchain, eventually I found that my old gcc
4.3.2 toolchain can still build workable u-boot and kernel so that
Linaro toolchain (gcc 4.6.2) seems the problem. I understand that
Linaro's focus has been ARMv7 or above but I am wondering if its
toolchain can still be used for older ARM architectures.
Thanks,
JD
Hi Michael,
A new bug triaging question.
https://bugs.launchpad.net/ubuntu/+source/ppl/+bug/941676
This one is special too because the failure is on powerpc.
This means, I cannot reproduce it easily, and scan through the toolchains
(without building).
Matthias has given some information and a guess of what is failing. My idea
was to just summarize this, and let the person who takes on the bug make
the powerpc investigation.
How do we handle bugs on other architectures in general?
Best regards
Åsa
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.
