[#5827] gcc.dg/trampoline-1.c test on hardware fdpic fails on bf527 but pass on bf548
Submitted By: Mingquan Pan
Open Date
2010-01-14 04:04:10 Close Date
2012-05-15 03:30:22
Priority:
Medium Assignee:
Steve Kilbane
Board:
N/A Silicon Revision:
Resolution:
Fixed Fixed In Release:
N/A
Processor:
BF527
Host Operating System:
toolchain rev.:
4.3 trunk head kernel rev.:
State:
Closed Found In Release:
Is this bug repeatable?:
Summary: gcc.dg/trampoline-1.c test on hardware fdpic fails on bf527 but pass on bf548
Details:
gcc.dg/trampoline-1.c test on hardware fdpic fails on bf527 and bf537 but pass on bf548.
On bf527:
test@45-bf527-toolchain:~/work/cruise/test_scripts/toolchain/toolchain-build> bfin-linux-uclibc-gcc /home/test/work/cruise/checkouts/toolchain/gcc-4.3/gcc/testsuite/gcc.dg/trampoline-1.c -O2 -DSTACK_SIZE=0x1f000 -DNO_TRAMPOLINES -fno-show-column -lm -mcpu=bf527-0.2 -o ./trampoline-1.exe
test@45-bf527-toolchain:~/work/cruise/test_scripts/toolchain/toolchain-build> rcp ./trampoline-1.exe root@10.100.4.50:/
test@45-bf527-toolchain:~/work/cruise/test_scripts/toolchain/toolchain-build> telnet 10.100.4.50
Trying 10.100.4.50...
Connected to 10.100.4.50.
Escape character is '^]'.
BusyBox v1.15.3 (2010-01-11 22:17:04 CST) hush - the humble shell
root:/> ls
bin init root trampoline-1.exe
dev lib sbin usr
etc mnt sys var
home proc tmp
root:/> ./trampoline-1.exe
Undefined instruction
<5> - May be used to emulate instructions that are not defined for
<5> a particular processor implementation.
Deferred Exception context
CURRENT PROCESS:
COMM=trampoline-1.ex PID=13146 CPU=0
TEXT = 0x009f4000-0x009f6cd0 DATA = 0x02fddcd0-0x02fdde84
BSS = 0x02fdde84-0x009c0000 USER-STACK = 0x009dfea0
return address: [0x009dfcd8]; contents of:
0x009dfcb0: 0000 3ff0 fdac 009d dde8 02fd ddd0 02fd
0x009dfcc0: ddd8 02fd fd4c 009d 0003 0000 fcd4 009d
0x009dfcd0: 0000 0000 e109 ddc8 [e149] 02fd e10a fcb4
0x009dfce0: e14a 009d ac4b 9149 0051 02f6 fd1c 009d
ADSP-BF527-0.2 525(MHz CCLK) 131(MHz SCLK) (mpu off)
Linux version 2.6.32.3-ADI-2010R1-pre-svn8139 (test@45-bf527-toolchain) (gcc version 4.3.4 (ADI-trunk/svn-3801) ) #22 Mon Jan 11 22:20:38 CST 2010
SEQUENCER STATUS: Not tainted
SEQSTAT: 00062021 IPEND: 0008 IMASK: ffff SYSCFG: 0006
EXCAUSE : 0x21
physical IVG3 asserted : <0xffa0069c> { _trap + 0x0 }
RETE: <0x00000000> /* Maybe null pointer? */
RETN: <0x02f56000> /* kernel dynamic memory */
RETX: <0x00000480> /* Maybe fixed code section */
RETS: <0x009f48c8> [ /trampoline-1.exe + 0x8c8 ]
PC : <0x009dfcd8> [ trampoline-1.ex + 0x1fcd8 ]
DCPLB_FAULT_ADDR: <0x009dfcd0> [ trampoline-1.ex + 0x1fcd0 ]
ICPLB_FAULT_ADDR: <0x009dfcd8> [ trampoline-1.ex + 0x1fcd8 ]
PROCESSOR STATE:
R0 : 00000000 R1 : 000002fd R2 : 009dfab4 R3 : 00000001
R4 : 02fddde0 R5 : 00000005 R6 : 00000000 R7 : 3ff00000
P0 : 009dfae8 P1 : 009dfcd4 P2 : 00000006 P3 : 00000000
P4 : 009dfd4c P5 : 02fdde08 FP : 009dfaec SP : 02f55f24
LB0: 009fc5a1 LT0: 009fc594 LC0: 00000000
LB1: 009f4879 LT1: 009f4878 LC1: 00000000
B0 : 00000137 L0 : 00000000 M0 : 000000b4 I0 : 009f5b10
B1 : 000000c0 L1 : 00000000 M1 : 00000001 I1 : 00000fff
B2 : 7ffff000 L2 : 00000000 M2 : 00001802 I2 : 00000000
B3 : 00000000 L3 : 00000000 M3 : 0000005b I3 : 00000006
A0.w: 00000000 A0.x: 00000000 A1.w: 00000000 A1.x: 00000000
USP : 009dfaa4 ASTAT: 02043024
Hardware Trace:
0 Target : <0x00004ff0> { _trap_c + 0x0 }
Source : <0xffa0062e> { _exception_to_level5 + 0x9a } CALL pcrel
1 Target : <0xffa00594> { _exception_to_level5 + 0x0 }
Source : <0xffa00450> { _bfin_return_from_exception + 0x18 } RTX
2 Target : <0xffa00438> { _bfin_return_from_exception + 0x0 }
Source : <0xffa004f4> { _ex_trap_c + 0x74 } JUMP.S
3 Target : <0xffa00480> { _ex_trap_c + 0x0 }
Source : <0xffa006f4> { _trap + 0x58 } JUMP (P4)
4 Target : <0xffa0069c> { _trap + 0x0 }
Source : <0x009dfcd6> [ trampoline-1.ex + 0x1fcd6 ] 0xddc8
5 Target : <0x009dfcd4> [ trampoline-1.ex + 0x1fcd4 ]
Source : <0x009f48c6> [ /trampoline-1.exe + 0x8c6 ] CALL (P1)
6 Target : <0x009f48c0> [ /trampoline-1.exe + 0x8c0 ]
Source : <0x009f48b0> [ /trampoline-1.exe + 0x8b0 ] IF !CC JUMP
7 Target : <0x009f484d> [ /trampoline-1.exe + 0x84d ]
Source : <0x009f4840> [ /trampoline-1.exe + 0x840 ] CALL pcrel
8 Target : <0x009f4820> [ /trampoline-1.exe + 0x820 ]
Source : <0x009f48b5> [ /trampoline-1.exe + 0x8b5 ]
9 Target : <0x009f484c> [ /trampoline-1.exe + 0x84c ]
Source : <0x009f492e> [ /trampoline-1.exe + 0x92e ] CALL pcrel
10 Target : <0x009f4916> [ /trampoline-1.exe + 0x916 ]
Source : <0x009f497a> [ /trampoline-1.exe + 0x97a ] IF CC JUMP
11 Target : <0x009f496e> [ /trampoline-1.exe + 0x96e ]
Source : <0x009e7fda> [ /lib/libgcc_s.so.1 + 0x7fda ] RTS
12 Target : <0x009e7fd2> [ /lib/libgcc_s.so.1 + 0x7fd2 ]
Source : <0x009e7ffa> [ /lib/libgcc_s.so.1 + 0x7ffa ] IF CC JUMP
13 Target : <0x009e7ff4> [ /lib/libgcc_s.so.1 + 0x7ff4 ]
Source : <0x009e7faa> [ /lib/libgcc_s.so.1 + 0x7faa ] IF CC JUMP
14 Target : <0x009e7fa4> [ /lib/libgcc_s.so.1 + 0x7fa4 ]
Source : <0x009e7fe6> [ /lib/libgcc_s.so.1 + 0x7fe6 ] IF CC JUMP
15 Target : <0x009e7fdc> [ /lib/libgcc_s.so.1 + 0x7fdc ]
Source : <0x009e7f9c> [ /lib/libgcc_s.so.1 + 0x7f9c ] IF CC JUMP
Userspace Stack
Stack info:
SP: [0x009dfaa4] <0x009dfaa4> [ trampoline-1.ex + 0x1faa4 ]
FP: (0x009dfaec)
Memory from 0x009dfaa0 to 009e0000
009dfaa0: 009dfb10 [009f5010] 02fdde08 009dfad8 009dfaec 009dfdac 009dfccc 009dfc4c
009dfac0: 009dfbcc 009dfb4c 00000000 009dfad4 00000000 ddc8e109 02fde149 fab4e10a
009dfae0: 009de14a 9149ac4b 10000051 (009dfb1c)<009f4844> 02fdde08 02fdddd8 3ff00000
009dfb00: 00000000 3ff00000 00000000 000002fd 009dfc4c 009dfccc 009dfd4c (009dfb6c)
009dfb20:<009f48b8><009f5010> 02fdde08 00000000 3ff00000 009dfdac 009dfd4c 009dfccc
009dfb40: 009dfc4c 009dfbcc 00000000 009dfb54 00000000 ddc8e109 02fde149 fb34e10a
009dfb60: 009de14a 9149ac4b 10000051 (009dfb9c)<009f4844> 02fdde08 02fdddd0 3ff00000
009dfb80: 00000000 bff00000 00000000 3ff00000 009dfccc 009dfd4c 02fdddd8 (009dfbec)
009dfba0:<009f48b8><009f5010> 02fdde08 00000000 bff00000 009dfdac 02fdddd8 009dfd4c
009dfbc0: 009dfccc 009dfc4c 00000001 009dfbd4 00000000 ddc8e109 02fde149 fbb4e10a
009dfbe0: 009de14a 9149ac4b 10000051 (009dfc1c)<009f4844> 02fdde08 02fddde8 3ff00000
009dfc00: 00000000 bff00000 00000000 bff00000 009dfd4c 02fdddd8 02fdddd0 (009dfc6c)
009dfc20:<009f48b8><009f5010> 02fdde08 00000000 bff00000 009dfdac 02fdddd0 02fdddd8
009dfc40: 009dfd4c 009dfccc 00000002 009dfc54 00000000 ddc8e109 02fde149 fc34e10a
009dfc60: 009de14a 9149ac4b 10000051 (009dfc9c)<009f4844> 02fdde08 02fdddc0 3ff00000
009dfc80: 00000000 3ff00000 00000000 bff00000 02fdddd8 02fdddd0 02fddde8 (009dfcec)
009dfca0:<009f48b8><009f5010> 02fdde08 00000000 3ff00000 009dfdac 02fddde8 02fdddd0
009dfcc0: 02fdddd8 009dfd4c 00000003 009dfcd4 00000000 ddc8e109 02fde149 fcb4e10a
009dfce0: 009de14a 9149ac4b 02f60051 (009dfd1c)<009f4844> 02fdde08 02fddde0 3ff00000
009dfd00: 00000000 <009f4fba> 02fdde08 009dfd38 02fdddd0 02fddde8 02fdddc0 (009dfd6c)
009dfd20:<009f48b8> 00000003 00000000 00000000 00000000 009dfdac 02fdddc0 02fddde8
009dfd40: 02fdddd0 02fdddd8 00000004 009dfd54 00000000 ddc8e109 02fde149 fd34e10a
009dfd60: 009de14a 9149ac4b 00000051 (009dfdac)<009f4932> 02fdde08 009f5b28 3ff00000
009dfd80: 00000000 009dfda8 <009ec204> 9999999a 02fddde8 02fdddc0 02fddde0 02fddde8
009dfda0: 02fdddc0 02fdddd0 02fdddd8 (009dfdd8)<009f4994> 009a5168 029926fc 009dff8e
009dfdc0: 009dff40 009dff60 00000001 00000000 009dff60 02fdde08 (009dfe64)<0092fece>
009dfde0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
009dfe00: 00000000 00000003 009f4034 00000004 00000020 00000005 00000006 00000006
009dfe20: 00001000 00000007 009f8000 00000008 00000000 00000009 009f44fc 00000000
009dfe40: 00000000 0000000b 00000000 0000000c 00000000 0000000d 00000000 0000000e
009dfe60: 00000000 (00000000)<009f452a> 02f6ab58 009f44fc 02f6ab40 009dff40 009dff60
009dfe80:<009f4500> 029926fc 009dff40 009dfea4 029926f4 029926ec 02f6ab40 009dff6c
009dfea0: 00000001 009dff8e 00000000 009dffa1 009dffac 009dffcf 009dffe3 00000000
009dfec0: 00000010 00000000 00000006 00001000 00000011 00000064 00000003 009f4034
009dfee0: 00000004 00000020 00000005 00000006 00000007 009f8000 00000008 00000000
009dff00: 00000009 009f44fc 0000000b 00000000 0000000c 00000000 0000000d 00000000
009dff20: 0000000e 00000000 00000017 00000000 0000001f 0001ffe9 00000000 00000000
009dff40: 00020000 009f8000 00000000 00004a88 02f6aa88 00005a88 00000264 00000000
009dff60: 00020000 009f4000 00000000 00002cd0 02fddcd0 00006cd0 000001b4 00000000
009dff80: 00000000 00000000 00000000 2f2e0000 6d617274 696c6f70 312d656e 6578652e
009dffa0: 52455400 696c3d4d 0078756e 48544150 69622f3d 752f3a6e 622f7273 2f3a6e69
009dffc0: 6e696273 73752f3a 62732f72 48006e69 5f485355 53524556 3d4e4f49 35312e31
009dffe0: 5000332e 2f3d4457 742f2e00 706d6172 6e696c6f 2e312d65 00657865 00000000
Return addresses in stack:
address : <0x009f5010> [ /trampoline-1.exe + 0x1010 ]
frame 1 : <0x009f4844> [ /trampoline-1.exe + 0x844 ]
frame 2 : <0x009f48b8> [ /trampoline-1.exe + 0x8b8 ]
frame 3 : <0x009f4844> [ /trampoline-1.exe + 0x844 ]
frame 4 : <0x009f48b8> [ /trampoline-1.exe + 0x8b8 ]
frame 5 : <0x009f4844> [ /trampoline-1.exe + 0x844 ]
frame 6 : <0x009f48b8> [ /trampoline-1.exe + 0x8b8 ]
frame 7 : <0x009f4844> [ /trampoline-1.exe + 0x844 ]
frame 8 : <0x009f48b8> [ /trampoline-1.exe + 0x8b8 ]
frame 9 : <0x009f4844> [ /trampoline-1.exe + 0x844 ]
address : <0x009f4fba> [ /trampoline-1.exe + 0xfba ]
frame 10 : <0x009f48b8> [ /trampoline-1.exe + 0x8b8 ]
frame 11 : <0x009f4932> [ /trampoline-1.exe + 0x932 ]
address : <0x009ec204> [ /lib/libgcc_s.so.1 + 0xc204 ]
frame 12 : <0x009f4994> [ /trampoline-1.exe + 0x994 ]
frame 13 : <0x0092fece> [ /lib/libc.so.0 + 0x2fece ]
frame 14 : <0x009f452a> [ /trampoline-1.exe + 0x52a ]
address : <0x009f4500> [ /trampoline-1.exe + 0x500 ]
ILL
root:/> echo $?
132
root:/> version
kernel: Linux release 2.6.32.3-ADI-2010R1-pre-svn8139, build #22 Mon Jan 11 22:20:38 CST 2010
toolchain: bfin-uclinux-gcc release gcc version 4.3.4 (ADI-trunk/svn-3801)
user-dist: release svn-9367, build #8 Mon Jan 11 22:19:16 CST 2010
root:/>
built the case with the same toolchain for bf548:
bfin-linux-uclibc-gcc /home/test/work/cruise/checkouts/toolchain/gcc-4.3/gcc/testsuite/gcc.dg/trampoline-1.c -O2 -DSTACK_SIZE=0x1f000 -DNO_TRAMPOLINES -fno-show-column -lm -mcpu=bf548-0.2 -o ./trampoline-1.exe
test@44-bf548-toolchain:~> rcp trampoline-1.exe root@10.100.4.50:/
test@44-bf548-toolchain:~> telnet 10.100.4.50
BusyBox v1.15.3 (2010-01-14 10:00:26 CST) hush - the humble shell
0
kernel: Linux release 2.6.32.3-ADI-2010R1-pre-svn8151, build #94 Thu Jan 14 10:03:07 CST 2010
user-dist: release svn-9376, build #32 Thu Jan 14 10:02:28 CST 2010
The two binary are attached.
And this case used to be falsely pass before the hush issue is fixed.
xecuting on host: bfin-linux-uclibc-gcc /home/test/work/cruise/checkouts/toolchain/gcc-4.3/gcc/testsuite/gcc.dg/trampoline-1.c -O2 -DSTACK_SIZE=0x1f000 -DNO_TRAMPOLINES -fno-show-column -lm -mcpu=bf527-0.2 -o ./trampoline-1.exe (timeout = 300)
spawn bfin-linux-uclibc-gcc /home/test/work/cruise/checkouts/toolchain/gcc-4.3/gcc/testsuite/gcc.dg/trampoline-1.c -O2 -DSTACK_SIZE=0x1f000 -DNO_TRAMPOLINES -fno-show-column -lm -mcpu=bf527-0.2 -o ./trampoline-1.exe^M
PASS: gcc.dg/trampoline-1.c (test for excess errors)
Executing on bfin-linux-uclibc: /tmp/trampoline-1.exe.27731 (timeout = 300)
Executing on bfin-linux-uclibc: rm -f /tmp/trampoline-1.exe.27731 (timeout = 300)
Executed ./trampoline-1.exe, status 0
PASS: gcc.dg/trampoline-1.c execution test
Follow-ups
--- Mingquan Pan 2010-02-03 21:58:10
It also fails on bf533 stamp but passes on bf561 ezkit in 4.1 gcc testing.
--- Steve Kilbane 2010-06-17 12:40:46
As far as I can tell, this comes down to the caches. The compiler implements
trampolines by generating some self-modified code pushed onto the stack, and the
icache isn't going to contain the same contents as the dcache. Turn off the
caches, and the problem goes away.
This is a known side-effect of the trampoline model: "Implementing
trampolines is difficult on many machines because they have separate instruction
and data caches. Writing into a stack location fails to clear the memory in the
instruction cache, so when the program jumps to that location, it executes the
old contents. Here are two possible solutions. One is to clear the relevant
parts of the instruction cache whenever a trampoline is set up. [...]"
GCC has a macro, CLEAR_INSN_CACHE(), to deal with this. I've tried enabling
this, and it provides libgcc with support for the __clear_cache builtin, but the
documentation implies that the compiler will use this builtin when generating
trampolines, if the macro's defined, but I can't get it to do so, and I can't
see any evidence in the sources to see where it would get added. Since the
internals docn covers 4.6 and I'm looking at 4.3, maybe that's why.
--- Robin Getz 2010-06-17 13:43:57
cache management is going to be pretty difficult due to the long standing, but
only recently tracked down IFLUSH bug....
the workaround is that IFLUSH can only be executed from L1 memory - which makes
it pretty difficult for a Linux application - since flat can't be split into a
external/internal memory model... The only thing to would be to have
__clear_cache:
- add a new system call for the non-elf compilers, which asked the kernel to
do the iflush - which will be pretty expensive, and defeats the purpose of doing
the trampoline in the first place...
- add a fixed code section, which jumps to code in L1 (I think this would be
the only option).
?
--- Sonic Zhang 2010-06-17 22:59:35
Do we really need to support this instruction code overlay features in GCC for
Linux application? I don't know any requirement under Linux. How about only
support it in bare metal gcc?
--- Mike Frysinger 2010-06-17 23:08:02
i dont think this is specific to code overlays. this is gcc generic trampolines
that it may generate under any OS.
http://gcc.gnu.org/onlinedocs/gccint/Trampolines.html
--- Michael Hennerich 2010-06-18 04:50:39
> - add a fixed code section, which jumps to code in L1 (I think this
> would be the only option).
Yeah - similar to what we do in fixed_code.c <asm/fixed_code.h> for the
atomic functions
--- Steve Kilbane 2010-06-18 07:05:07
I'll look into this, then.
The gcc docs also propose an alternative solution: "The other is to make
all trampolines identical, by having them jump to a standard subroutine." I
don't see how that helps, but I might try it out to see what code it generates.
--- Robin Getz 2010-06-18 09:42:15
Sonic:
>Do we really need to support this instruction code overlay features in
>GCC for Linux application?
Like Mike, I don't think this has anything to do with code overlay features.
Its about putting code on the stack, and executing it.
gcc-4.3/gcc/testsuite/gcc.dg/trampoline-1.c
Looks like pretty standard (well, maybe not common) userspace code to me...
upon further poking - it's may not even be very "standard"...
(Steve could comment) - my understanding is that while gcc accepts this, and it
runs on other architectures fine, ISO C (iso9899:1990 & iso9899:1999)
forbids nested functions, and this test case is for a gnu extension to the C
language... (at least that is what -ansi -pedantic says).
I did check, and this "feature" is also supported by icc, RVDS &
other c compilers, so it's difficult to say how "in the wild" this
construct is.
-Robin
--- Mike Frysinger 2010-06-18 10:27:16
ive seen people use nested code in open source projects. it isnt terribly
common, but it isnt rare either.
--- Steve Kilbane 2010-06-18 11:26:53
It's not just the nested functions (which are non-standard) - it's the passing
of pointers to them, too.
I'll do a bit more investigation (been busy with other things today), but my
inclination is to file this one under "turn off the cache for now",
and to look at some of the other bugs at equivalent priority which crop up in
more generic contexts
--- Steve Kilbane 2010-06-18 11:28:48
Hmm, realised my last comment was ambiguous. I don't mean "define a nested
function which takes pointer-typed parameters", I mean "define a
nested function, take the address of it, and then pass that function pointer to
another function to call."
--- Robin Getz 2010-06-18 13:44:17
I don't think "turn off cache" is a workaround.
It would be better to ensure that gcc turns this into an ICE - rather than
generating the iffy trampoline code - so we can scope out how many people
complain about it...
--- Sonic Zhang 2010-06-21 01:45:51
This walkaround may cause problem if running application under SMP kernel.
No fixed L1 SRAM is available under SMP kernel.
Does IFLUSH work well in L2 SRAM on bf561?
--- Steve Kilbane 2010-06-21 06:35:57
I assume that "ICE" is "internal compiler error", right?
Bleagh. I wonder if it's possible to configure the compiler so that it doesn't
support constructs that require trampolines, instead (so that you get high-level
error rather than the compiler barfing in the back end).
--- Robin Getz 2010-06-21 08:56:23
Steve:
>I assume that "ICE" is "internal compiler error",
right?
Yes. It's pretty bad - but you would get an idea how many times this comes up.
>Bleagh.
I agree - but silently failing is worse.
>Does IFLUSH work well in L2 SRAM on bf561?
No. (But this is outside the scope of this bug - this is something that is part
of Mike's recent checkins - see r8860 in the kernel - "allow cache funcs to
be in L1 for anomaly 491" - it's not really 'allow', its more 'force' - as
it's the only way to ensure that IFLUSH works.)
--- Steve Kilbane 2010-07-08 05:56:40
Committed change to config/bfin/bfin.c so that we throw an internal compiler
error if you take the address of a nested function definition, as proposed by
Robin. This means that a whole bunch of nested-function tests will now fail:
PASS->FAIL: gcc.c-torture/compile/20010226-1.c -O0 (test for excess
errors)
PASS->FAIL: gcc.c-torture/compile/20010226-1.c -O1 (test for excess
PASS->FAIL: gcc.c-torture/compile/20010226-1.c -O2 (test for excess
PASS->FAIL: gcc.c-torture/compile/20010226-1.c -O3 -fomit-frame-pointer
(test for excess errors)
PASS->FAIL: gcc.c-torture/compile/20010226-1.c -O3 -g (test for excess
PASS->FAIL: gcc.c-torture/compile/20010226-1.c -Os (test for excess
PASS->FAIL: gcc.c-torture/compile/20050122-2.c -O0 (test for excess
PASS->FAIL: gcc.c-torture/compile/20050122-2.c -O1 (test for excess
PASS->FAIL: gcc.c-torture/compile/20050122-2.c -O2 (test for excess
PASS->FAIL: gcc.c-torture/compile/20050122-2.c -O3 -fomit-frame-pointer
PASS->FAIL: gcc.c-torture/compile/20050122-2.c -O3 -g (test for excess
PASS->FAIL: gcc.c-torture/compile/20050122-2.c -Os (test for excess
PASS->FAIL: gcc.c-torture/compile/nested-1.c -O0 (test for excess errors)
PASS->FAIL: gcc.c-torture/compile/nested-1.c -O1 (test for excess errors)
PASS->FAIL: gcc.c-torture/compile/nested-1.c -O2 (test for excess errors)
PASS->FAIL: gcc.c-torture/compile/nested-1.c -O3 -fomit-frame-pointer
PASS->FAIL: gcc.c-torture/compile/nested-1.c -O3 -g (test for excess
PASS->FAIL: gcc.c-torture/compile/nested-1.c -Os (test for excess errors)
PASS->FAIL: gcc.c-torture/compile/pr27889.c -O0 (test for excess errors)
PASS->FAIL: gcc.c-torture/compile/pr27889.c -O1 (test for excess errors)
PASS->FAIL: gcc.c-torture/compile/pr27889.c -O2 (test for excess errors)
PASS->FAIL: gcc.c-torture/compile/pr27889.c -O3 -fomit-frame-pointer (test
for excess errors)
PASS->FAIL: gcc.c-torture/compile/pr27889.c -O3 -g (test for excess
PASS->FAIL: gcc.c-torture/compile/pr27889.c -Os (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gdwarf-21 -O3 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gdwarf-21 -O (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gdwarf-21 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gdwarf-23 -O3 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gdwarf-23 -O (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gdwarf-23 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gdwarf-2 -O3 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gdwarf-2 -O (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gdwarf-2 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gstabs+1 -O3 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gstabs1 -O3 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gstabs+1 -O (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gstabs1 -O (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gstabs+1 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gstabs1 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gstabs+3 -O3 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gstabs3 -O3 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gstabs+3 -O (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gstabs3 -O (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gstabs+3 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gstabs3 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gstabs -O3 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gstabs+ -O3 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gstabs -O (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gstabs+ -O (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gstabs (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-3.c -gstabs+ (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gdwarf-21 -O3 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gdwarf-21 -O (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gdwarf-21 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gdwarf-23 -O3 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gdwarf-23 -O (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gdwarf-23 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gdwarf-2 -O3 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gdwarf-2 -O (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gdwarf-2 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gstabs+1 -O3 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gstabs1 -O3 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gstabs+1 -O (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gstabs1 -O (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gstabs+1 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gstabs1 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gstabs+3 -O3 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gstabs3 -O3 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gstabs+3 -O (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gstabs3 -O (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gstabs+3 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gstabs3 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gstabs -O3 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gstabs+ -O3 (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gstabs -O (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gstabs+ -O (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gstabs (test for excess errors)
PASS->FAIL: gcc.dg/debug/debug-5.c -gstabs+ (test for excess errors)
PASS->FAIL: gcc.dg/nested-func-5.c (test for excess errors)
PASS->FAIL: gcc.dg/pr34457-1.c (test for excess errors)
PASS->FAIL: gcc.dg/torture/nested-fn-1.c -O0 (test for excess errors)
PASS->FAIL: gcc.dg/torture/nested-fn-1.c -O1 (test for excess errors)
PASS->FAIL: gcc.dg/torture/nested-fn-1.c -O2 (test for excess errors)
PASS->FAIL: gcc.dg/torture/nested-fn-1.c -O3 -fomit-frame-pointer (test
PASS->FAIL: gcc.dg/torture/nested-fn-1.c -O3 -g (test for excess errors)
PASS->FAIL: gcc.dg/torture/nested-fn-1.c -Os (test for excess errors)
PASS->FAIL: gcc.dg/trampoline-1.c (test for excess errors)
I assume I should update these tests to NOTSUPPORTED for now, until we can get
a workaround that can employ IFLUSH?
--- Robin Getz 2010-07-08 11:11:21
Lets wait a day or so - so see if anything in userspace shakes out, and we see
the same issue with real code...
Just building up toolchains for me now...
--- Vivi Li 2010-07-13 04:28:39
I also see these failures in gcc4.3 test.
--- Steve Kilbane 2010-07-29 04:18:00
Three weeks since we changed to aborting on trampoline creation - anything
cropping up in userspace since then, or can we leave that in for this release?
--- Mike Frysinger 2010-07-29 11:10:58
i havent seen anything, so leaving for this release should be OK
--- Sonic Zhang 2010-07-30 01:07:27
Down priority to 3 for this release.
--- Robin Getz 2010-07-30 13:03:34
How many userspace libraries/applications have we tried building with the new
toolchain? directfb? sdl? ffmpeg? .... ???
While I agree it doesn't appear to be a problem in the things I have been using
- I question how much coverage do we have...
--- Sonic Zhang 2010-08-01 23:52:46
Not that much. I am still waiting for Vivi to finish kernel testing with the
ALPHA2 toolchain.
--- Steve Kilbane 2010-08-16 06:30:51
Bumping this back up to P2, since #6186 shows that rlogin.c runs into this. Gah.
--- Vivi Li 2010-08-16 06:34:56
The new toolchain works well to build these tools and libs.
--- Steve Kilbane 2010-08-16 07:12:48
I'm confused - #6186 is reported against 2010R1-ALPHA2. To which new toolchain
are you referring?
--- Mike Frysinger 2010-08-16 13:54:52
i guess we'll have to extend the fixed code section a bit for an iflush
trampoline
--- Sonic Zhang 2010-08-16 21:28:39
Source code built in bug 6186 is not from our SVN.
--- Steve Kilbane 2010-08-23 06:37:19
Some progress here: Thanks to assistance from Ian Lance Taylor, I have a
compiler that's generating calls to __clear_cache() which is, in turn, making a
call to flushing code in the fixed-address area (which should really be calling
to L1 to flush, rather flushing directly, but that's next). I need to check
whether I need to do something special for FDPIC support for bfin-linux-uclibc
(tests are passing, but that might just be luck).
It looks to me like the ld scripts for bfin-elf map everything to L1 anyway, so
I can just have __clear_cache() flush directly, for that target. Is it
necessary, though? What's the cache situation for bfin-elf targets? Enabled by
U-Boot? Enabled by CRT? Off unless application explicitly enables?
--- Mike Frysinger 2010-08-23 19:40:24
the Linux userspace ABI shouldnt matter as the calls should always be direct and
not through a PLT or something. there should be existing examples in the
Blackfin gcc code where the atomic functions are used. Bernd was particularly
found of keeping the addresses low so that they could be done with two insns:
P0 = 0x400 (z);
CALL (P0);
the *default* ld scripts with the bfin-elf toolchain maps everything to L1.
you cant make any assumption about the location of anything there. same goes
for the cache state ... the behavior of the default CRT objects dont really
matter as users are free (and encouraged) to supplement their own.
the best course probably is to have the bfin-elf compiler generate references
to a __clear_cache() function that the C library needs to provide. then in our
libgloss port, we can define that function, declare it as weak, and place it in
.l1.text. if someone needs something more, they're free to override it with
their own.
--- Steve Kilbane 2010-08-24 05:26:48
I've seen TARGET_FDPIC is defined when building bfin-linux-uclibc - I presume
there's something defined so that I can tell when it's a bfin-elf build?
--- Mike Frysinger 2010-08-24 13:04:23
you will want the logic the other way around -- only use the fixed code region
when targeting the Linux OS.
TARGET_FDPIC is autoexpanded from bfin.opt, and exists because our default
specs use -mfdpic for bfin-linux-uclibc targets.
i guess we would want a new Target -mlinux option in bfin.opt like -mfdpic, and
have this in the default spec for uclinux.h and linux.h. then you can key off
of TARGET_LINUX in the rest of the blackfin code.
--- Steve Kilbane 2010-08-25 02:56:07
> you will want the logic the other way around -- only use the fixed code
region
Well, yes. But that's two out of three toolchain targets, hence wondering
whether to tell we were building the third. :-)
The mention of the .opt files is sufficient pointer, thanks - I'll take a look
at those.
--- Mike Frysinger 2010-08-25 03:03:47
*we* build three toolchains, two of which target linux. that doesnt mean other
people cant build other non-linux tuples (and there are more).
however, ignoring even that, generally the open source view isnt "if linux
is common, we'll special case the rest". the drive is for the correct
answer. in this case, the fixed code abi is a linux-only feature which means
usage of that address has to be tied to linux.
--- Steve Kilbane 2010-08-25 11:28:52
I'm calling it __clear_cache_range(), since libgcc defines __clear_cache(),
non-weak, sans section, using CLEAR_INSN_CACHE as the body if defined. So in the
non-TARGET_LINUX case, __clear_cache() will just call __clear_cache_range().
--- Mike Frysinger 2010-08-25 21:54:51
sounds fine. as long as document things, i'm sure the name you choose will be
ok. as long as it isnt EAT_A_KITTEN() or something ;).
--- Vivi Li 2010-08-26 06:49:26
Can we mark those tests with "internal compiler error" as NOTSUPPORTED
now? Too many failures makes regression log difficult to check.
--- Stuart Henderson 2010-08-26 11:54:38
That should be them disabled now, vivi. let me know if i've missed any.
--- Vivi Li 2010-08-27 06:38:09
Hi Stuart,
Please take a look at bellow tests. They've also got "internal compiler
error".
--
gcc.c-torture/compile/930506-2.c -O0 (internal compiler error)
gcc.c-torture/compile/930506-2.c -O1 (internal compiler error)
gcc.c-torture/compile/930506-2.c -O2 (internal compiler error)
gcc.c-torture/compile/930506-2.c -O3 -fomit-frame-pointer (internal compiler
error)
gcc.c-torture/compile/930506-2.c -O3 -g (internal compiler error)
gcc.c-torture/compile/930506-2.c -Os (internal compiler error)
gcc.c-torture/execute/20000822-1.c compilation, -O0 (internal compiler
gcc.c-torture/execute/20000822-1.c compilation, -O1 (internal compiler
gcc.c-torture/execute/20000822-1.c compilation, -O2 (internal compiler
gcc.c-torture/execute/20000822-1.c compilation, -O3 -fomit-frame-pointer
(internal compiler error)
gcc.c-torture/execute/20000822-1.c compilation, -O3 -g (internal compiler
gcc.c-torture/execute/20000822-1.c compilation, -Os (internal compiler
gcc.c-torture/execute/nestfunc-3.c compilation, -O0 (internal compiler
gcc.c-torture/execute/nestfunc-3.c compilation, -O1 (internal compiler
gcc.c-torture/execute/nestfunc-3.c compilation, -O2 (internal compiler
gcc.c-torture/execute/nestfunc-3.c compilation, -O3 -fomit-frame-pointer
-funroll-loops (internal compiler error)
-funroll-all-loops -finline-functions (internal compiler error)
gcc.c-torture/execute/nestfunc-3.c compilation, -O3 -g (internal compiler
gcc.c-torture/execute/nestfunc-3.c compilation, -Os (internal compiler
gcc.c-torture/execute/nestfunc-5.c compilation, -O0 (internal compiler
gcc.c-torture/execute/nestfunc-5.c compilation, -O1 (internal compiler
gcc.c-torture/execute/nestfunc-5.c compilation, -O2 (internal compiler
gcc.c-torture/execute/nestfunc-5.c compilation, -O3 -fomit-frame-pointer
gcc.c-torture/execute/nestfunc-5.c compilation, -O3 -g (internal compiler
gcc.c-torture/execute/nestfunc-5.c compilation, -Os (internal compiler
gcc.c-torture/execute/nestfunc-6.c compilation, -O0 (internal compiler
gcc.c-torture/execute/nestfunc-6.c compilation, -O1 (internal compiler
gcc.c-torture/execute/nestfunc-6.c compilation, -O2 (internal compiler
gcc.c-torture/execute/nestfunc-6.c compilation, -O3 -fomit-frame-pointer
gcc.c-torture/execute/nestfunc-6.c compilation, -O3 -g (internal compiler
gcc.c-torture/execute/nestfunc-6.c compilation, -Os (internal compiler
gcc.dg/20050607-1.c (internal compiler error)
--- Vivi Li 2010-08-27 06:54:31
In the list above, except for gcc.dg/20050607-1.c, other failures happen only
on bfin-elf.
Vivi
--- Stuart Henderson 2010-08-27 13:05:45
thanks, i've updated the tests.
--- Vivi Li 2010-08-31 02:28:13
The tests I mentioned last time still fail in latest trunk.
-Vivi
--- Vivi Li 2010-08-31 03:06:07
The lasted source code is not updated in our local server, so the test result
remains the same. We are looking into local server to make sure source code is
the latest. I'll update the test result later.
--- Vivi Li 2010-08-31 23:54:46
Build bellow file still fail with bfin-elf.
gcc.c-torture/execute/20000822-1.c
gcc.c-torture/execute/nestfunc-3.c
gcc.c-torture/execute/nestfunc-5.c
gcc.c-torture/execute/nestfunc-6.c
--- Vivi Li 2010-09-29 02:47:08
trampoline test case is not run on 2010 branch.
UNSUPPORTED: gcc.dg/trampoline-1.c
--- Vivi Li 2010-10-12 04:36:05
gcc.dg/trampoline-1.c test case is now passed on 2010r1 branch(since rc4)
--- Sonic Zhang 2010-10-12 22:28:25
I think this bug can be marked fixed.
--- Mingquan Pan 2012-05-15 04:30:24
Yeah, I can see this case also pass on bf537 stamp board and bf527 ezkit board
now. So close.
Executing on host: bfin-linux-uclibc-gcc
/home/test/work/cruise/checkouts/toolchain/gcc-4.3/gcc/testsuite/gcc.dg/trampoline-1.c
-O2 -DSTACK_SIZE=0x1f000 -DNO_TRAMPOLINES -fno-show-column -lm
-mcpu=bf527-0.2 -o ./trampoline-1.exe (timeout = 300)
spawn bfin-linux-uclibc-gcc
-O2 -DSTACK_SIZE=0x1f000 -DNO_TRAMPOLINES -fno-show-column -lm -mcpu=bf527-0.2
-o ./trampoline-1.exe^M
Executing on bfin-linux-uclibc: /tmp/trampoline-1.exe.7023 {} {} (timeout =
300)
spawn [open ...]^M
XYZ0ZYX
Executing on bfin-linux-uclibc: rm -f /tmp/trampoline-1.exe.7023 (timeout =
Files
Changes
Commits
Dependencies
Duplicates
Associations
Tags
File Name File Type File Size Posted By
548_trampoline-1.exe application/octet-stream 47345 Mingquan Pan
527_trampoline-1.exe application/octet-stream 47345 Mingquan Pan