Re: [microblaze-uclinux] Microblaze with MMU, possible stack corruption in loadable module?

[jeffrey.fuller@xxxxxxxxx]

Hi All, 

It looks like we have a work-around
for the problem described below. John, it is similar to the work-around
you gave us for the printk problem we had. In arch/microblaze/module.c

               
 case R_MICROBLAZE_32:
                    
    old_value = ((location[0] & 0x0000FFFF) << 16)
|
                    
                    (location[1]
& 0x0000FFFF);
                    
    //value += old_value;
^^^^^ COMMENT OUT THIS LINE ^^^^^^^^^
                    
    location[0] = (location[0] & 0xFFFF0000) |

Previously, we had commented out the
same line for the R_MICROBLAZE_64 case.

Regards,
Jeff

Jeff Fuller
Software Engineer
EI WW SOFTWARE SYSTEMS ENGINEERING

Eastman Kodak Company
2400 Mt Read Blvd.
Rochester, NY 14650-3019

jeffrey.fuller@xxxxxxxxx
Office: (585)726-6908
www.kodak.com

jeffrey.fuller@xxxxxxxxx
Sent by: owner-microblaze-uclinux@xxxxxxxxxxxxxx

05/28/2008 04:58 PM

Please respond to
microblaze-uclinux@xxxxxxxxxxxxxx

To	microblaze-uclinux@xxxxxxxxxxxxxx
cc
Subject	[microblaze-uclinux] Microblaze with MMU, possible stack corruption in loadable module?

Hi John (and everyone else), 

I am attaching some code that compiles into a loadable module. It will
allow anyone who is interested to recreate a problem I'm having. This is
on Microblaze with MMU. The code I am attaching is based on code in a real
driver module, but has specifics removed and is made as simple as possible.

I'm seeing strange behavior when I call a function implemented in one .c
file from another .c file. If I move the function into the same .c file,
the weirdness goes away. Further, not all function calls across compilation
units behave badly. I've only got one example of it happening - some other
calls I make don't seem to have problems. The function that does have a
problem, though, is much longer that the others. It contains a lengthy
switch statement. If you take the switch statement out or make it have
fewer cases, the problem may go away. The problem itself is everything
from the called function having local variables or function parameters
get their values changed, to seeing the function run several (or more)
times even though it's only called once, to causing an Oops. Here is one
example of an Oops I got: 

Oops: Exception in kernel mode, sig: 4 
  Registers dump: mode=1 
  sp=DF8B5E70, r2=00000000, r3=00000038, r4=E005B330
  r5=0000000E, r6=0000000E, r7=00000000, r8=00000000
  r9=C03AF5A8, r10=00000000, r11=00000000, r12=C004C8AC
  r13=00000000, r14=00000001, r15=E005B24C, r16=000000D0
  r17=10001A64, r18=00000005, r19=00001000, r20=BFB96EF4
  r21=00000000, r22=C01AF374, r23=00000010, r24=DF8B4000
  r25=000200D0, r26=C00339A4, r27=C03AB7D8, r28=C0007534
  r29=00000001, r30=00000000, r31=C0374040, rPC=E005B334
  ear=DF8E3000, esr=00001000 
Illegal instruction 

Anyway, on to the example: 
1. Compile the file1.h, file.c, and main.c files into a loadable module.
2. load the module. 
3. cat /proc/testdriver 
4. This is the output I get: 
        ProcFunction 
        Oops: Exception in kernel mode, sig: 4
        register listing.... 
5. Now, go to line 191 of main.c and comment it out
6. Go to line 192 of main.c and uncomment it. 
7. Rebuild and load the module. 
8. cat /proc/testdriver 
9. This is the output I get (and it is the output I should have got in
step 4.) 
        ProcFucntion 
        14 Switch Val = 14. 

The difference between the incorrect and correct versions is that in step
4, the output is coming from functions in file1.c (proc funciton in main.c,
output functions in file1.c), while in step 9, all the functions are in
main.c. Basically, the main.c file contains copies of the functions in
file1.c - they just have the prefix "Proc" added to all the function
names so as to avoid collisions. By commenting/uncommenting lines 191 and
192 in main.c, you can choose whether main.c 's proc output function calls
a function in file.c or in main.c. Both set of functions are identical
(except for their names). This illustrates the problem I am having in calling
functions in another compilation unit. 

You can vary the parameter passed to the PrintSwitch/ProcPrintSwitch functions
on line 191 and 192 of main.c and get different behavior. For example,
changing the parameter from 14 (which it is in the file I am attaching)
to 3 (which means the output should say "3 Switch Val = 3." produces
the correct output when keeping all calls in main.c. It produce the output
"9 Switch Val = 9." when the call goes out to file1.c, however.
Note that no oops is produced in this case! 

Any help is appreciated. Not sure if this is some sort of stack corruption
or long jump problem or what. 

Thanks in advance,
Jeff

Jeff Fuller
Software Engineer
EI WW SOFTWARE SYSTEMS ENGINEERING

Eastman Kodak Company
2400 Mt Read Blvd.
Rochester, NY 14650-3019

jeffrey.fuller@xxxxxxxxx
Office: (585)726-6908
www.kodak.com

Attachment: main.c
Description: Binary data

Attachment: file1.h
Description: Binary data

Attachment: file1.c
Description: Binary data