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

[jeffrey.fuller@xxxxxxxxx]

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