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

Piet Delaney pdelaney at tensilica.com
Mon Jun 27 22:37:38 PDT 2011


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>
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 <mailto: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 <mailto: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 <mailto: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 <mailto:piet at tensilica.com>'
>
>     Cc: 'marc at tensilica.com <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <http://www.wipro.com>
>
>                 _______________________________________________
>
>                 linux-xtensa mailing list
>
>                 linux-xtensa at linux-xtensa.org <mailto: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 <http://www.wipro.com>
>
>         _______________________________________________
>
>         linux-xtensa mailing list
>
>         linux-xtensa at linux-xtensa.org <mailto: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 <http://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 <http://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 <http://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/20110627/6d85d9f9/attachment-0001.html


More information about the linux-xtensa mailing list