[#5827] gcc.dg/trampoline-1.c test on hardware fdpic fails on bf527 but pass on bf548

Document created by Aaronwu Employee on Oct 17, 2013
Version 1Show Document
  • View in full screen mode

[#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:

N/A

Is this bug repeatable?:

N/A     

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 ]

    address : <0x009f5010> [ /trampoline-1.exe + 0x1010 ]

   frame  3 : <0x009f4844> [ /trampoline-1.exe + 0x844 ]

   frame  4 : <0x009f48b8> [ /trampoline-1.exe + 0x8b8 ]

    address : <0x009f5010> [ /trampoline-1.exe + 0x1010 ]

   frame  5 : <0x009f4844> [ /trampoline-1.exe + 0x844 ]

   frame  6 : <0x009f48b8> [ /trampoline-1.exe + 0x8b8 ]

    address : <0x009f5010> [ /trampoline-1.exe + 0x1010 ]

   frame  7 : <0x009f4844> [ /trampoline-1.exe + 0x844 ]

   frame  8 : <0x009f48b8> [ /trampoline-1.exe + 0x8b8 ]

    address : <0x009f5010> [ /trampoline-1.exe + 0x1010 ]

   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

Trying 10.100.4.50...

Connected to 10.100.4.50.

Escape character is '^]'.

 

 

BusyBox v1.15.3 (2010-01-14 10:00:26 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

root:/> echo $?

0

root:/> version

kernel:    Linux release 2.6.32.3-ADI-2010R1-pre-svn8151, build #94 Thu Jan 14 10:03:07 CST 2010

toolchain: bfin-uclinux-gcc release gcc version 4.3.4 (ADI-trunk/svn-3801)

user-dist: release svn-9376, build #32 Thu Jan 14 10:02:28 CST 2010

root:/>                                                                      

 

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

ILL

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

>  - add a fixed code section, which jumps to code in L1 (I think this

> would be the only option).

 

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.

 

Sonic:

>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

errors)

PASS->FAIL: gcc.c-torture/compile/20010226-1.c  -O2  (test for excess

errors)

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

errors)

PASS->FAIL: gcc.c-torture/compile/20010226-1.c  -Os  (test for excess

errors)

PASS->FAIL: gcc.c-torture/compile/20050122-2.c  -O0  (test for excess

errors)

PASS->FAIL: gcc.c-torture/compile/20050122-2.c  -O1  (test for excess

errors)

PASS->FAIL: gcc.c-torture/compile/20050122-2.c  -O2  (test for excess

errors)

PASS->FAIL: gcc.c-torture/compile/20050122-2.c  -O3 -fomit-frame-pointer

(test for excess errors)

PASS->FAIL: gcc.c-torture/compile/20050122-2.c  -O3 -g  (test for excess

errors)

PASS->FAIL: gcc.c-torture/compile/20050122-2.c  -Os  (test for excess

errors)

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

(test for excess errors)

PASS->FAIL: gcc.c-torture/compile/nested-1.c  -O3 -g  (test for excess

errors)

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

errors)

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

for excess errors)

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...

 

-Robin

 

--- 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

when targeting the Linux OS.

 

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

error)

gcc.c-torture/execute/20000822-1.c compilation,  -O1  (internal compiler

error)

gcc.c-torture/execute/20000822-1.c compilation,  -O2  (internal compiler

error)

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

error)

gcc.c-torture/execute/20000822-1.c compilation,  -Os  (internal compiler

error)

gcc.c-torture/execute/nestfunc-3.c compilation,  -O0  (internal compiler

error)

gcc.c-torture/execute/nestfunc-3.c compilation,  -O1  (internal compiler

error)

gcc.c-torture/execute/nestfunc-3.c compilation,  -O2  (internal compiler

error)

gcc.c-torture/execute/nestfunc-3.c compilation,  -O3 -fomit-frame-pointer

(internal compiler error)

gcc.c-torture/execute/nestfunc-3.c compilation,  -O3 -fomit-frame-pointer

-funroll-loops  (internal compiler error)

gcc.c-torture/execute/nestfunc-3.c compilation,  -O3 -fomit-frame-pointer

-funroll-all-loops -finline-functions  (internal compiler error)

gcc.c-torture/execute/nestfunc-3.c compilation,  -O3 -g  (internal compiler

error)

gcc.c-torture/execute/nestfunc-3.c compilation,  -Os  (internal compiler

error)

gcc.c-torture/execute/nestfunc-5.c compilation,  -O0  (internal compiler

error)

gcc.c-torture/execute/nestfunc-5.c compilation,  -O1  (internal compiler

error)

gcc.c-torture/execute/nestfunc-5.c compilation,  -O2  (internal compiler

error)

gcc.c-torture/execute/nestfunc-5.c compilation,  -O3 -fomit-frame-pointer

(internal compiler error)

gcc.c-torture/execute/nestfunc-5.c compilation,  -O3 -g  (internal compiler

error)

gcc.c-torture/execute/nestfunc-5.c compilation,  -Os  (internal compiler

error)

gcc.c-torture/execute/nestfunc-6.c compilation,  -O0  (internal compiler

error)

gcc.c-torture/execute/nestfunc-6.c compilation,  -O1  (internal compiler

error)

gcc.c-torture/execute/nestfunc-6.c compilation,  -O2  (internal compiler

error)

gcc.c-torture/execute/nestfunc-6.c compilation,  -O3 -fomit-frame-pointer

(internal compiler error)

gcc.c-torture/execute/nestfunc-6.c compilation,  -O3 -g  (internal compiler

error)

gcc.c-torture/execute/nestfunc-6.c compilation,  -Os  (internal compiler

error)

gcc.dg/20050607-1.c (internal compiler error)

--

 

--- Vivi Li                                                  2010-08-27 06:54:31

Hi Stuart,

 

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

Hi Stuart,

 

The tests I mentioned last time still fail in latest trunk.

 

-Vivi

 

--- Vivi Li                                                  2010-08-31 03:06:07

Hi Stuart,

  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

 

--- 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

/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.7023 {} {}   (timeout =

300)

spawn [open ...]^M

XYZ0ZYX

Executing on bfin-linux-uclibc: rm -f  /tmp/trampoline-1.exe.7023    (timeout =

300)

spawn [open ...]^M

XYZ0ZYX

Executed ./trampoline-1.exe, status 0

PASS: gcc.dg/trampoline-1.c execution test

 

 

 

    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

Outcomes