[Linux-Xtensa] Kernel module compilation problem on linux (2.6.29) running LX2 customized core with customized TIE instructions.

ananth.sundapalayam at wipro.com ananth.sundapalayam at wipro.com
Wed Jun 29 07:10:19 PDT 2011


Hi Piet,

I tried this in the cycle-accurate mode; it was much slower.

 

The last message is "NET: Registered protocol family 1". 

It has been at this for the past ½ hr or so.

I've enabled the breakpoint at do_page_fault().

Let me see if it breaks there.

 

Will keep you updated.

 

Thanks,
Ananth

 

 

 

 

From: Piet Delaney [mailto:pdelaney at tensilica.com] 
Sent: Tuesday, June 28, 2011 11:08 AM
To: Ananth Sundapalayam (WT01 - WT - Internal Vertical); linux-xtensa at linux-xtensa.org
Cc: Piet Delaney; Marc Gauthier
Subject: Re: [Linux-Xtensa] Kernel module compilation problem on linux (2.6.29) running LX2 customized core with customized TIE instructions.

 

ananth.sundapalayam at wipro.com wrote:



Hi Piet,

I'm facing another problem now.

 

Since the dynamic module linking (using xt-ld) is not okay 

(even with the fix in the RD-2011.2 release)

I compiled in the driver modules, using TIE, statically & tried to bring up the kernel.

 

It comes up but, doesn't give the console at all; the last message it throws up is:

free_initmem: Freeing unused/init kernel memory: .... 2484K freed

 Hi Ananth:

Looks like I was right  and you likely experiencing a simulator problem; not a problem with the kernel code.
I followed Marc's suggestion of tracing the code just before the page fault code was recording a bogus PC
in the ptregs structure.

The simulation appears to be executing a branch at an unmapped page boundary. 
Further the branch is to an address in the unmapped page. This is an extremely rare situation.
Instead of backing out the instruction, letting the page fault code map in the page, and then re-executing the 
branch instuction, it unfortunately changed  the PC and so it's no longer possible to re-execute the branch correctly
after the page fault maps in the page.

I filed a PR on it (22875) and we will let you know as soon as it's fixed.

I tested it with --turbo disabled and after about ten minutes it had gotten up to running portmapper:

#0  0xd01533e8 in strlen (s=0xd02fa649 "PageFault[1685], Ccount:661509381, do_page_fault(): [0 S13portma"...) at lib/string.c:371
tsk:0xd02cb170->{pid:    0, cpus_allowed:1, state: 0, running:1, mm:0x00000000,                                       comm:'swapper'}
tsk:0xd7814bc0->{pid:    1, cpus_allowed:1, state: 1, running:1, mm:0xd78b2de0->{asid[ 0]:0x0000009f, total_vm:  260},     comm:'init'}
tsk:0xd78148e0->{pid:    2, cpus_allowed:1, state: 1, running:1, mm:0x00000000,                                       comm:'kthreadd'}
tsk:0xd7814600->{pid:    3, cpus_allowed:1, state: 1, running:1, mm:0x00000000,                                       comm:'ksoftirqd/0'}
tsk:0xd7814320->{pid:    4, cpus_allowed:1, state: 1, running:1, mm:0x00000000,                                       comm:'events/0'}
tsk:0xd7814040->{pid:    5, cpus_allowed:1, state: 1, running:1, mm:0x00000000,                                       comm:'khelper'}
tsk:0xd784cbe0->{pid:    6, cpus_allowed:1, state: 1, running:1, mm:0x00000000,                                       comm:'kblockd/0'}
tsk:0xd784c900->{pid:    7, cpus_allowed:1, state: 1, running:1, mm:0x00000000,                                       comm:'pdflush'}
tsk:0xd784c620->{pid:    8, cpus_allowed:1, state: 1, running:1, mm:0x00000000,                                       comm:'pdflush'}
tsk:0xd784c340->{pid:    9, cpus_allowed:1, state: 1, running:1, mm:0x00000000,                                       comm:'kswapd0'}
tsk:0xd784c060->{pid:   10, cpus_allowed:1, state: 1, running:1, mm:0x00000000,                                       comm:'aio/0'}
tsk:0xd788fc00->{pid:   11, cpus_allowed:1, state: 1, running:1, mm:0x00000000,                                       comm:'nfsiod'}
tsk:0xd788f640->{pid:   16, cpus_allowed:1, state: 1, running:1, mm:0x00000000,                                       comm:'rpciod/0'}
tsk:0xd788f360->{pid:   24, cpus_allowed:1, state: 1, running:1, mm:0xd78b2ae0->{asid[ 0]:0x000000ad, total_vm:  291},     comm:'rcS'}
tsk:0xd788f080->{pid:   25, cpus_allowed:1, state: 1, running:1, mm:0xd78b2960->{asid[ 0]:0x000000c2, total_vm:  292},     comm:'S13portmap'}
#0  0xd01533e8 in strlen (s=0xd02fa649 "PageFault[1685], Ccount:661509381, do_page_fault(): [0 S13portma"...) at lib/string.c:371
(gdb) 


    PageFault[1557], Ccount:494077047, do_page_fault(): [0 S13portmap:25:2007c8a4:18:2007c8a4:x]
    PageFault[1558], Ccount:495398053, do_page_fault(): [0 S13portmap:25:2001e9c8:18:2001e9c8:x]
    PageFault[1559], Ccount:496715469, do_page_fault(): [0 S13portmap:25:20036614:18:20036614:x]
    PageFault[1560], Ccount:498033742, do_page_fault(): [0 S13portmap:25:00479cac:26:004188aa:]

With --turbo enabled it appears we are executing a branch incorrectly much earlier; at around PageFault[87].

I'll check in an updated .xt-gdbinit file in case your interested replicating how this is diagnosed. 
It might be worth trying it if you expect to be doing a lot of simulation work; it's pretty slick.

I prepared for doing the ISS trace by:
    1. starting the simulation at trace level 0, 
    2. setting a breakpoint at do_page_fault(), 
    3. enabling page_fault_debug, and 
    4. doing a continue 83 to bring me to the page fault just before the problem occurs. 

I then enabled ISS tracing and let it continue, hitting the do_page_fault() breakpoint one more time. 

Here you can see in the iss trace  EPC1 getting a 1 put into it:
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 107714 [ 0x0040eff9 0x07f56ff9 7 ] (130871713) 0x07 0xa9             "s32i.n a10,a7,0"
 107715  <__bss_end+0xe3879>
 107716         a10: AR[26] -> 0x3f985fd4
 107717         a7: AR[23] -> 0x0047ff5c
 107718         CCOUNT <- 0x07ccf131
 107719 [ 0x0040effb 0x07f56ffb 7 ] (130871714) 0x00 0x0a 0x92          "l8ui a9,a10,0"
 107720  <__bss_end+0xe387b>
 107721         a10: AR[26] -> 0x3f985fd4
 107722         a9: AR[25] <- 0x0000002f
 107723         CCOUNT <- 0x07ccf132
 107724 [ 0x0040effe 0x07f56ffe 7 ] (130871715)                            "<no issue>"                                 [BUG]
 107725  <__bss_end+0xe387e>
 107726         a9: AR[25] -> 0x0000002f
 107727         a8: AR[24] -> 0x0000002d
 107728         CCOUNT <- 0x07ccf133
 107729         $branch( "Taken", 0x0040efaa )
 107730 [ 0x0040efaa 0x07f56faa 7 ] (130871716) 0x00 0x02 0xe0              "callx8 a2"                                 [BUG - PC moved back]
 107731  <__bss_end+0xe382a>
 107732         a2: AR[18] -> 0x00000001
 107733         PSCALLINC <- 0x2
 107734         a8: AR[24] <- 0x8040efad
 107735         CCOUNT <- 0x07ccf134
 107736         $branch( "Call", 0x00000001 )
 107737 [ 0x00000001 ? ? ] (130871717)                                     "<no issue>"
 107738  <+0x1>
 107739         EPC1 <- 0x00000001                                                                                      [BUG!]
 107740         PSEXCM <- 0x1
 107741         EXCVADDR <- 0x00000001
 107742         EXCCAUSE <- 0x10
 107743         $exception("InstTLBMissException")
 107744         $branch( "Exception", 0xd0000340 )
 107745 [ 0xd0000340 0x00000340 7 ] (130871717) 0x61 0xd1 0x30        "xsr.excsave1 a3"
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

The user space init code is easiest available in your buildroot staging directory,  /sbin/init points to busybox:

            /buildroot-xtensa-HiFi2-Snapshot/project_build_xtensa_dc233c/dc233c/root/bin/busybox
       
$ xt-gdb busybox
GNU gdb (GDB) 7.1 Xtensa Tools 9.0.2-development
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> <http://gnu.org/licenses/gpl.html> 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=xtensa-elf"...
Reading symbols from /export2/DC_C_233L/src/buildroot-xtensa-HiFi2-Snapshot/project_build_xtensa_dc233c/dc233c/root/bin/busybox...(no debugging symbols found)...done.
 
(xt-gdb) x/10i 0x0040eff9
   0x40eff9 <_start+889>:       s32i.n  a10, a7, 0
   0x40effb <_start+891>:       l8ui    a9, a10, 0
   0x40effe <_start+894>:       bne     a9, a8, 0x40f005 <_start+901>
   0x40f001 <_start+897>:       addi.n  a8, a10, 1
   0x40f003 <_start+899>:       s32i.n  a8, a7, 0
   0x40f005 <_start+901>:       l32r    a8, 0x406364
   0x40f008 <_start+904>:       l32i.n  a10, a7, 0
   0x40f00a <_start+906>:       callx8  a8
   0x40f00d <_start+909>:       s32i.n  a10, a7, 0
   0x40f00f <_start+911>:       l32r    a10, 0x406368
(xt-gdb) 

Notice that the branch instruction is branching to the next page which
isn't mapped. Also note that the 1st two bytes of the branch instruction are
in the current page and the third byte of the branch instruction is in 
the un-mapped page that caused the InstTLBMissException.

-piet






 

After this, it is supposed to run init & the various rc scripts; 

but, it seems to've hung there & doesn't output any messages after that nor give the console.

 

Any idea why this could be happening?

 

Thanks,
Ananth.

 

 

From: Piet Delaney [mailto:pdelaney at tensilica.com] 
Sent: Thursday, June 23, 2011 2:08 PM
To: Ananth Sundapalayam (WT01 - WT - Internal Vertical)
Cc: Piet Delaney; Marc Gauthier; Anand Pradhan
Subject: Re: [Linux-Xtensa] Kernel module compilation problem on linux (2.6.29) running LX2 customized core with customized TIE instructions.

 

ananth.sundapalayam at wipro.com wrote: 

Hi Piet,

I've attached my .config.

I don't have any other changes in the kernel.

 

Thanks very much for all your help.


I extracted your config from the xcf file and I'm building it now.
I was curious about the Run_Stall.tie file. Since your ISS problem
might be involved with your config  could you tell me more about it
while I'm waiting for the tools to be built. I see the RunStall.tie file
is building a FLIX system with two slots and that it's involved in
a memory consistency model. Do you have any pagers on this to
give me a bit better idea what to expect?

Tomorrow I'll compare you sari file and Environment.sr to our
dc233c sari files to give me a better feel for how your variant
differs from the norm. Hopefully the tools will build fine this
evening and I can build a root file-system and compile the kernel
with your config file.

Any high-level docs on generally what your doing with your
variant could save me time. So far everything looked resonavble,
your using a MMU and the prom locations looked reasonable.

-piet






 

Best Regards,

Ananth.

 

From: Piet Delaney [mailto:pdelaney at tensilica.com] 
Sent: Friday, June 17, 2011 12:54 PM
To: Ananth Sundapalayam (WT01 - WT - Internal Vertical)
Cc: Piet Delaney; Anand Pradhan; Marc Gauthier
Subject: Re: [Linux-Xtensa] Kernel module compilation problem on linux (2.6.29) running LX2 customized core with customized TIE instructions.

 

ananth.sundapalayam at wipro.com wrote: 

Hi Piet,
I've attached the .xcf & the .tie file that I'm using.
  

Ok, I'll build some tools for it.






 
Let me know if you want something more.
  

Send me your .config file and if any of your kernel source code
if different put it on a branch and I'll pull it.

-piet






 
Thanks a lot!
 
Best Regards,
Ananth
 
-----Original Message-----
From: Marc Gauthier [mailto:marc at tensilica.com]
Sent: Tuesday, June 14, 2011 11:23 PM
To: Ananth Sundapalayam (WT01 - WT - Internal Vertical); Piet Delaney
Cc: Anand Pradhan
Subject: RE: [Linux-Xtensa] Kernel module compilation problem on linux
(2.6.29) running LX2 customized core with customized TIE instructions.
 
Anand,
 
The slightly mismatched kernel version of kernel headers is
not likely to be an issue.  It's how we usually build buildroot
actually...
 
So possible next steps could be either your providing Piet details of
your
config (.xcf file and TIE etc) so he can reproduce the issue, if you're
okay with sharing that, or else you can start debugging the issue,
as Piet suggested.
 
Thanks!
-Marc
 
 
 
ananth.sundapalayam at wipro.com wrote:
  

	Hi Piet,
	The buildroot (from git) is using linux-2.6.27 kernel, i.e.,
	the dl/ dir contains linux-2.6.27.18.tar.bz2.
	The iss_defconfig is present under the directory
	buildroot/toolchain_build_xtensa_cp0/
	linux-2.6.27.18/arch/xtensa/configs/iss_defconfig.
	 
	Whereas, I am using linux-2.6.29 kernel from git.
	 
	Could this mismatch be the problem?
	 
	I tried to experiment by keeping linux-2.6.29.tar.bz2 inside
	the buildroot/dl/ dir., and, recompiling buildroot - it didn't work!
	The buildroot compilation looks for linux-2.6.27.18.
	 
	Thanks & Regards,
	Ananth.
	 
	 
	 
	 
	 
	 
	-----Original Message-----
	From: Ananth Sundapalayam (WT01 - WT - Internal Vertical)
	Sent: Tuesday, June 14, 2011 3:12 PM
	To: 'piet at tensilica.com'
	Cc: 'marc at tensilica.com'
	Subject: RE: [Linux-Xtensa] Kernel module compilation problem on linux
	(2.6.29) running LX2 customized core with customized TIE instructions.
	 
	Hi Piet,
	I am using the iss_defconfig that is generated after I've built the
	buildroot patched with my core conf. overlay file.
	 
	    

		It smells like an incompatability
		between your config and the root filesystem your using. I get
		problems like this when I try to boot a on a root filesystem from
		the wrong config.
		      

	I installed the overlay & built the buildroot; the root
	filesystem got
	built alongwith the buildroot.
	Anyway, I'll check on this point.
	 
	Thanks,
	Ananth
	 
	 
	 
	 
	 
	-----Original Message-----
	From: Piet Delaney [mailto:piet.delaney at gmail.com]
	Sent: Tuesday, June 14, 2011 2:51 PM
	To: Ananth Sundapalayam (WT01 - WT - Internal Vertical)
	Cc: marc at tensilica.com
	Subject: Re: [Linux-Xtensa] Kernel module compilation problem on linux
	(2.6.29) running LX2 customized core with customized TIE instructions.
	 
	On 6/13/2011 2:51 AM, ananth.sundapalayam at wipro.com wrote:
	    

		Hi,
		I have been able to bring up the kernel.
		However, there seems to be a problem with the initial login prompt.
		After the kernel has come up, just as the login prompt is about come
		up,
		 
		I keep getting an error repeatedly while waiting for the prompt.
		 
		It shows the welcome message followed by the "uclibc login:" prompt.
		This is immediately followed by a message : "getty: ttyS0: read:
		Resource temporarily unavailable".
		 
		Sometimes this is followed by a message which says:
		do_illegal_instruction: Illegal Instruction on cpu:0 in
		tsk:d331f340->comm:'getty' (pid = 148, pc =0x0040efff).
		(NOTE: the tsk id&  pid/pc vary. And, this message doesn't appear
		everytime).
		 
		This keeps happening repeatedly.
		 
		I am finally able to get the prompt after about 20-25 mins..
		      

	I haven't seen this problem and didn't have time today to try to
	reproduce it. Are you using the dc233c_iss_defconfig as a starting
	point?
	 
	I recommend putting a break point in do_illegal_instruction()  and
	showing us more detail about stuff like pt_regs, the code at the PC,
	the code at
	the
	uncache PC address, etc. It smells like an incompatability
	between your config and the root filesystem your using. I get problems
	like this when I try to boot a on a root filesystem from the wrong
	config.
	 
	Eventually I'll need you config file so I can build Xtensa Tools
	matching your processor. I'm at home, as I recall it's a file ending
	with .cfg. I'll let you know wends morning.
	 
	 
	-piet
	 
	    

		Thanks&  Regards,
		Ananth
		 
		 
		 
		-----Original Message-----
		From: Ananth Sundapalayam (WT01 - WT - Internal Vertical)
		Sent: Friday, March 25, 2011 7:15 PM
		To: 'Piet Delaney'; linux-xtensa at linux-xtensa.org
		Subject: RE: [Linux-Xtensa] Kernel module compilation problem on
		linux (2.6.29) running LX2 customized core with customized TIE
		instructions.
		 
		Hi Piet,
		Thanks for your response.
		I enabled CONFIG_CC_OPTIMIZE_FOR_DEBUGGING&  tried to recompile the
		kernel. It is now saying:
		 
		 
		*** Default compiler does not appear to target an Xtensa core.
		*** It didnt understand the -mlongcalls GCC option
		*** Please put an appropriate Xtensa toolchain on your PATH
		 
		CROSS_COMPILE:                    xt-
		PLATFORM:                         iss
		VARIANT:                          cp0
		KBUILD_CFLAGS:                    -Wall -Wundef -Wstrict-prototypes
		-Wno-trigraphs -fno-strict-aliasing -fno-common
		-Werror-implicit-function-declaration -O2 -ffreestanding -mlongcalls
		-pipe   -fomit-frame-pointer
		VARIANT_DIR:                      arch/xtensa/variants/cp0/
		PLATFORM_DIR:                     arch/xtensa/platforms/iss/
		 
		We never got this kind of an error before.
		I checked the $PATH, $XTENSA_CORE, $XTENSA_SYSTEM variables - they
		are properly set.
		 
		Could you kindly help?
		 
		Thanks,
		Ananth
		 
		 
		-----Original Message-----
		From: Piet Delaney [mailto:pdelaney at tensilica.com]
		Sent: Friday, March 25, 2011 12:38 PM
		To: Ananth Sundapalayam (WT01 - WT - Internal Vertical)
		Cc: linux-xtensa at linux-xtensa.org
		Subject: Re: [Linux-Xtensa] Kernel module compilation problem on
		linux (2.6.29) running LX2 customized core with customized TIE
		instructions.
		 
		Piet Delaney wrote:
		      

			ananth.sundapalayam at wipro.com wrote:
			        

				Hi,
				 
				We are using a customized Xtensa LX2 core with customized TIE
				instructions. We are facing a problem while compiling a linux
				kernel module - a linux driver for a device that interfaces with
				the core using TIE ports. We are using the C 'TIE  APIs' in the
				driver.
				We were able to compile&  link a plain C driver for the same
				device in XTOS. However, the linux overlay of our processor type
				did not generate the requisite headers&  libs; hence, our module
				failed to compile for linux kernel.
				 
				We learnt from Tensilica support that we needed to compile with
				xcc(xt-xcc). When we weren't able to do so, we moved to a newer
				kernel version (2.6.29) instead of 2.6.24. We have now been able
				to download&  compile the linux 2.6.29 kernel. Subsequently, we
				tried to compile the module using xcc.
				Now, we are getting the following errors:
				 
				                 We disabled the option Xtensa processor type and
				features ->  System supports SMP(MX). Now The latest linux kernel
				was compiled successfully.
				 
				                 But the problem we are facing is, that when I
				enable the option, Xtensa processor type and features ->Use XCC
				Tensilica's Optimized, Vectorizing Xtensa compiler. We are getting
				the below error. Error :
				/mnt/xt/xtensa-linux/linux/include/linux/hrtimer.h:420: warning:
				'no_instrument_function' attribute directive ignored
				In file included from
				/mnt/xt/xtensa-linux/linux/include/linux/sched.h:91,
				from /mnt/xt/xtensa-linux/linux/include/linux/utsname.h:36,
				                  from
				          

	/mnt/xt/xtensa-linux/linux/init/version.c:13:
	    

				/mnt/xt/xtensa-linux/linux/include/linux/cred.h:158: warning:
				'no_instrument_function' attribute directive ignored    LD
				   init/built-in.o LD      .tmp_vmlinux1
				kernel/built-in.o:(.text+0x1168): undefined reference to
				`__xchg_called_with_bad_pointer'
				kernel/built-in.o: In function `__xchg':
				exit.c:(.text+0xad5e): undefined reference to
				`__xchg_called_with_bad_pointer'
				kernel/built-in.o:(.text+0x3000): undefined reference to
				`__xchg_called_with_bad_pointer'
				kernel/built-in.o: In function `__xchg':
				mutex.c:(.text+0x1a176): undefined reference to
				`__xchg_called_with_bad_pointer'
				kernel/built-in.o:(.text+0x38f4): undefined reference to
				`__cmpxchg_called_with_bad_pointer'
				kernel/built-in.o: In function `__cmpxchg':
				rtmutex.c:(.text+0x1fe8e): undefined reference to
				`__cmpxchg_called_with_bad_pointer'
				fs/built-in.o:(.text+0x23f0): undefined reference to
				`__xchg_called_with_bad_pointer'
				fs/built-in.o: In function `__xchg':
				namespace.c:(.text+0x14eb6): undefined reference to
				`__xchg_called_with_bad_pointer'
				fs/built-in.o: In function `rootfs_get_sb':
				inode.c:(.text+0x3bd40): undefined reference to
				`__cmpxchg_called_with_bad_pointer'
				fs/built-in.o: In function `__cmpxchg':
				unlink.c:(.text+0x4733e): undefined reference to
				`__cmpxchg_called_with_bad_pointer'
				net/built-in.o: In function `kernel_sock_shutdown':
				(.text+0x1b80): undefined reference to
				          

		`__xchg_called_with_bad_pointer'
		      

				net/built-in.o: In function `__xchg':
				sock.c:(.text+0x43ae): undefined reference to
				`__xchg_called_with_bad_pointer'
				net/built-in.o: In function `genl_ctrl_event':
				genetlink.c:(.text+0x1b2a4): undefined reference to
				`__xchg_called_with_bad_pointer'
				net/built-in.o: In function `__xchg':
				ip_sockglue.c:(.text+0x2609e): undefined reference to
				`__xchg_called_with_bad_pointer'
				make[1]: *** [.tmp_vmlinux1] Error 1
				make: *** [sub-make] Error 2
				[root at Kalimuthu linux]# make O=../build-iss/ ARCH=xtensa menuconfig
				   GEN     /mnt/xt/xtensa-linux/build-iss/Makefile
				scripts/kconfig/mconf arch/xtensa/Kconfig
				make[2]: *** [menuconfig] Error 1
				make[1]: *** [menuconfig] Interrupt
				make: *** [sub-make] Interrupt
				          

			Hi Ananth:
			 
			Sorry for the delay answering your mail, I've been rather busy on
			an important kernel enhancement.
			 
			Looks like ya just don't have:
			 
			    CONFIG_CC_OPTIMIZE_FOR_DEBUGGING
			 
			configured. I'll update the Kconfig to better explain this mess and
			consolidate two existing workarounds and put it in one area.
			 
			When I first started working on Xtensa-Linux I had to hack the
			kernel in a few places to compensate for a bug in our compiler so
			that I could compile the kernel with
			        

		optimization disabled. I've since
		      

			begged our XCC developers to fix the compiler to be more compatible
			with GCC. One problem is that even with optimization disabled, the
			conventional GCC compiler will
			        

		not generate the code to call a
		      

			function that can never be called.
			 
			For example:
			 
			    if (0)
			            __xchg_called_with_bad_pointer()
			 
			GCC notices that the argument to the 'if' statement above is a
			constant thus the code can never be called and it peep-hole
			optimizes it way in the front end of the GCC compiler. XCC also
			uses the GCC front end but I don't recall hearing the exact reason
			that our XCC guru's didn't want to enable it.
			 
			XCC has this problem worse than our Xtensa GCC which has this
			pathology a bit. GCC for other architectures is apparently bug free
			as far as optimizing out code that can't be called. Looks like a
			slam dunk to me to implement it. It would be very interesting to
			hear a detailed explanation for why it's so nasty to enable it
			completely in both XCC and our Xtensa GCC. I recently added this
			fragment to work around the problem
			        

	for XCC in
	    

		various places in the kernel:
		 
		      

	--------------------------------------------------------------
	----------
	    

		-----------------------
		      

			                            arch/xtensa/mm/init.c
			 
			        

	--------------------------------------------------------------
	----------
	    

		-----------------------
		      

			   33 #ifdef __XCC__
			   34 /*
			   35  * Functions that gcc optimizes away but has extern
			   statements for. 36  * XCC doesn't optimize them away via the GCC
			   frontend; sigh.    37  */ 38 void __attribute__ ((weak))
			   __get_user_bad(void) { panic(__func__); } 39 void __attribute__
			   ((weak)) __put_user_bad(void) { panic(__func__); } 40 void
			   __attribute__ ((weak)) _NSIG_WORDS_is_unsupported_size(void) {
			   panic(__func__); } 41 void __attribute__ ((weak))
			   __bad_unaligned_access_size(void) { panic(__func__); }    42 43
			   int __attribute__ ((weak)) verify_compat_iovec(void) {
			   panic(__func__); } 44 int __attribute__ ((weak))
			   cmsghdr_from_user_compat_to_kern(void) { panic(__func__); } 45
			   int __attribute__ ((weak)) get_compat_msghdr(void) {
			panic(__func__); } 46 int __attribute__ ((weak))
			put_cmsg_compat(void) { panic(__func__); } 47 int __attribute__
			((weak)) scm_detach_fds_compat(void) { panic(__func__); } 48 int
			__attribute__ ((weak)) cookie_v4_init_sequence(void) {
			panic(__func__); }    49 #endif
			 
			        

	--------------------------------------------------------------
	----------
	    

		-------------------------
		      

			It provides dummy functions in case the compile generated code to
			call them. Being as it's the same bug to different degrees in both
			our GCC and XCC I'm now of the belief that it's likely best to
			remove the
			        

		CONFIG_CC_OPTIMIZE_FOR_DEBUGGING workaround
		      

			in mm/slab.c and arch/xtensa/include/asm/system.h and instead add
			the ghost functions to the workaround in init.c; Something like:
			 
			 
			        

	--------------------------------------------------------------
	----------
	    

		-----------------------
		      

			                    arch/xtensa/mm/init.c
			 
			        

	--------------------------------------------------------------
	----------
	    

		-----------------------
		      

			   33 #if defined(__XCC__) ||
			        

	defined(CONFIG_CC_OPTIMIZE_FOR_DEBUGGING)
	    

			   34 /*
			   35  * Functions that gcc optimizes away but has extern
			   statements for. 36  * XCC doesn't optimize them away via the GCC
			   front end; sigh.    37  */ 38 void __attribute__ ((weak))
			   __get_user_bad(void) { panic(__func__); } 39 void __attribute__
			   ((weak)) __put_user_bad(void) { panic(__func__); } 40 void
			   __attribute__ ((weak)) _NSIG_WORDS_is_unsupported_size(void) {
			   panic(__func__); } 41 void __attribute__ ((weak))
			   __bad_unaligned_access_size(void) { panic(__func__); }    42 43
			   int __attribute__ ((weak)) verify_compat_iovec(void) {
			   panic(__func__); } 44 int __attribute__ ((weak))
			   cmsghdr_from_user_compat_to_kern(void) { panic(__func__); } 45
			   int __attribute__ ((weak)) get_compat_msghdr(void) {
			   panic(__func__); } 46 int __attribute__ ((weak))
			   put_cmsg_compat(void) { panic(__func__); } 47 int __attribute__
			((weak)) scm_detach_fds_compat(void) { panic(__func__); } 48 int
			__attribute__ ((weak)) cookie_v4_init_sequence(void) {
			panic(__func__); }    + +  void __attribute__ ((weak))
			__xchg_called_with_bad_pointer(void) { panic(__func__); }   <-- ADD
			        

+
  

			void __attribute__ ((weak))
			        

		__cmpxchg_called_with_bad_pointer(void)     { panic(__func__); }
		<-- ADD
		      

			   +  void __attribute__ ((weak)) __bad_size(int size) {
			panic(__func__); }<-- ADD    49 #endif
			 
			        

	--------------------------------------------------------------
	----------
	    

		-------------------------
		      

			This would be less evasive and would make it unnecessary to hack
			generic kernel code. I'll try it out and update the 2.6.29-smp git
			repo it it works as I expect it should.
			 
			In summary, as a workaround for now, just configure in
			        

		CONFIG_CC_OPTIMIZE_FOR_DEBUGGING.
		      

			I'll continue to bug our XCC developers to make XCC 100.000% GCC
			compatible.
			        

		I dug into the problem this evening and localize it two three
		patterns:
		 
		         1. if ( 0&  expr)
		                  dead code
		 
		          2. switch(constant) {
		                  case constant:
		 
		                  default: dead code
		             }
		 
		          3. static inline function(constant)
		             {
		                  if (constant)
		                          ...
		                          return()
		 
		                  else
		                          dead code
		             }
		 
		It's only a problem when you debug the kernel and it compiled
		without optimization; for good reason.
		 
		I'll likely file an XCC enhancement request on it tomorrow and unify
		the the kernel workarounds in a week or two. Got a customer problem
		to get back to.
		 
		Let me know if that work-around doesn't work for ya.
		 
		-piet
		 
		 
		      

			Let me know if you would like an account of linux-xtensa.org so you
			can submit bug-fixes and enhancements yourself in the future. The
			buildroot folks want us to update our Xtensa buildroot patches in
			the near future; the more help the better.
			 
			-piet
			        

					From /arch/xtensa/Makefile, we came to know that, to
					            

	cross-compile
	    

		with
		      

				xt-xcc, we need to define "CONFIG_USE_XTENSA_XCC_COMPILER".
				 
				That was the reason we enabled  " Use XCC  Tensilica's Optimized,
				Vectorizing Xtensa compiler" opition.
				 
				We are compiling the module as follows:
				 
				                 $ make ARCH=xtensa
				 
				                 Is this the correct way? Since CROSS_COMPILE
				option is already set in [/arch/xtensa/]Makefile itself
				 
				 
				ifdef CONFIG_USE_XTENSA_XCC_COMPILER
				  CROSS_COMPILE := xt-
				  CC := $(CROSS_COMPILE)xcc
				else
				# Test for GCC cross compiling. Allow xtensa-*-* and
				  xtensa_<variant>-*-* ifneq ($(SUBARCH),$(ARCH))
				   ifeq ($(CROSS_COMPILE),)
				     CROSS_COMPILE := $(call cc-cross-prefix, \
				                                        xtensa-linux-uclibc-
				xtensa_$(VARIANT)-linux-uclibc- \
				                                        xtensa-linux-gnu-
				   xtensa_$(VARIANT)-linux-gnu-) endif
				  endif
				endif
				 
				Thanks&  Regards,
				Ananth.
				 
				 
				Please do not print this email unless it is absolutely necessary.
				 
				The information contained in this electronic message and any
				          

		attachments to this message are intended for the exclusive use of the
		addressee(s) and may contain proprietary, confidential or privileged
		information. If you are not the intended recipient, you should not
		disseminate, distribute or copy this e-mail. Please notify the sender
		immediately and destroy all copies of this message and any
		      

	attachments.
	    

				WARNING: Computer viruses can be transmitted via email. The
				          

	recipient
	    

		should check this email and any attachments for the presence of
		viruses. The company accepts no liability for any damage caused by
		any virus transmitted by this email.
		      

				www.wipro.com
				_______________________________________________
				linux-xtensa mailing list
				linux-xtensa at linux-xtensa.org
				http://lists.linux-xtensa.org/mailman/listinfo/linux-xtensa
				 
				          

		Please do not print this email unless it is absolutely necessary.
		 
		The information contained in this electronic message and any
		      

	attachments to this message are intended for the exclusive use of the
	addressee(s) and may contain proprietary, confidential or privileged
	information. If you are not the intended recipient, you should not
	disseminate, distribute or copy this e-mail. Please notify the sender
	immediately and destroy all copies of this message and any
	attachments.
	    

		WARNING: Computer viruses can be transmitted via email. The
		      

	recipient
	should check this email and any attachments for the presence
	of viruses.
	The company accepts no liability for any damage caused by any virus
	transmitted by this email.
	    

		www.wipro.com
		_______________________________________________
		linux-xtensa mailing list
		linux-xtensa at linux-xtensa.org
		http://lists.linux-xtensa.org/mailman/listinfo/linux-xtensa
		      

	 
	Please do not print this email unless it is absolutely necessary.
	 
	The information contained in this electronic message and any
	attachments to this message are intended for the exclusive
	use of the addressee(s) and may contain proprietary,
	confidential or privileged information. If you are not the
	intended recipient, you should not disseminate, distribute or
	copy this e-mail. Please notify the sender immediately and
	destroy all copies of this message and any attachments.
	 
	WARNING: Computer viruses can be transmitted via email. The
	recipient should check this email and any attachments for the
	presence of viruses. The company accepts no liability for any
	damage caused by any virus transmitted by this email.
	 
	www.wipro.com
	    

 
Please do not print this email unless it is absolutely necessary.
 
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
 
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
 
www.wipro.com
  

 

Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. 

www.wipro.com 

 

Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. 

www.wipro.com 

 


Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. 

www.wipro.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-xtensa.org/pipermail/linux-xtensa/attachments/20110629/c56063b4/attachment-0001.html


More information about the linux-xtensa mailing list