[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
Wed Jun 29 23:38:10 PDT 2011


ananth.sundapalayam at wipro.com wrote:
>
> Hi Piet,
>
Hi Ananth,
>
> I tried this in the cycle-accurate mode; it was much slower.
>
Yea, but the good news is that our *ISS team jumped right on it *
and appear to have fixed the bug this afternoon! I'm testing the
fix right now; feels great.

>  
>
> 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.
>
I'm currently  testing ISS with dc233c, I'd like to get
the Linux Test Suite(LTP)  running thru completion and see
an FAIL/PASS ratio around the same as for FPGA boards
and real customers chips on development boards.
As I recall the typical FAII/PASS ratio is now down to
about a percent and LTP runs with lots of compiling
and other CPU loads for at least a week or two.

I'm currently building a buildroot and kernel for your config.
I've been calling it '*wipro'*. If that's acceptable to you,
I could check the config into the local source kernel and buildroot
git repos. Then you could easily let me know if yours differ significantly.
Also, just compiled the kernel with XCC for your VARIANT and got
one undefined symbol which I'm about to fix.

Even more important, I'm setting up regression tests to build buildroot.
kernels, and U-Boot for a handful of  configurations/cores/variants.
If your config is checked in it would be easy to not only check
dc233c with ISS running LTP but also yours and those of other customers
that would like the possibility of their variants and platforms tested 
frequently
before a releases and updates. I think this might help avoid any 
unnecessary surprises
like we had with ISS this week. I've been very busy with other stuff
but this event has made more aware of how important it is  to have the
regression test running a wide spectrum of Xtensa Linux test prior to a
releases and updates.

Let me know if you like the idea , and if name '*wipro*' is ok with you,
or  if you have a preferable alternate. The name is suppose to be:
    * descriptive
    * short
    * only alphanumerics and _ characters

This name is only part of the name of the gcc compiler version name
and it's parsed by autoconfig and related tools.

I tentatively picked  '*wipro*'  the other night because everyone here 
will know what the config is,
and  if it's mentioned in one of the regression logs the context will be 
obvious to everyone. It's not
locked in stone, we can also always change it later if ya prefer.

I was impressed with your projects goal. I'll continue on
the module loading patches and try to get them on the
master branch ASAP.  In the mean time are you plaining
of running the simulator with multiple variants? If so I
was wondering if you have or could put together a framework,
even with the currently slow citation, that I could try before the next
release update goes out to see if there is anything else that I could 
address
pro-actively for ya. If I find anything wrong with ISS simulation the 
kernel
running LPT I'll let ya know and try to fix it.

-piet


>  
>
> 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 <mailto: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 <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/20110629/83b1241f/attachment-0001.html


More information about the linux-xtensa mailing list