QEMU Segmentation Fault

[rayrayy]

Hi, when we compile nested function calls with arguments, such as the following,

int f(int a, int b){
    return a + b ;
}

int g(int a) {
    return a;
}

int fmain(){
    int a = 1;
    int b = 2;
    return f(g(a), b);
}

we get uncaught target signal 11 (segmentation fault) - core dumped when we run it in QEMU. However, the same code can be run without issues in MARS. Additionally, the code without the argument like below compiled to run fine.

int f(int a, int b){
    return a + b ;
}

int g() {
    return 1;
}

int fmain(){
    int a = 1;
    int b = 2;
    return f(g(), b);
}

For the record, we have tried to both use the argument registers $a0-$a3, as well as direct storage in memory for the arguments.

We were wondering if there were any similar known issues, as we are very confused about why the compiled MIPS code could output the correct value in MARS but not QEMU. Thanks in advance!

[JaafarRammal]

I compiled the code and it works fine. It appears that you have a problem with allocating memory for your arguments during the function calls.

More info here

[tobhil98]

I think you need to specify your parameter type for g in the first example. int g( int a );

[rayrayy]

I think you need to specify your parameter type for g in the first example. int g( int a );

Hi, that was actually a mistake on my end when I was writing the post. We have narrowed down the issue to incorrect allocation of memory as Jaafar has suggested above. Is there a rule that prevents QEMU to access memory below $sp such as sw $t0, -8($sp)?

[JaafarRammal]

You might be accessing the frame of another function. Since you used MARS, I would suggest re-checking where you are writing in the memory. I am pretty sure it will work because MARS doesn't have the concept of frames. Try to follow the stack pointer and I can guarantee you are writing in the frame of the previous function.

There is an option to debug in MARS and keep track of where the stack pointer is writing in memory

[rayrayy]

Oh I see! So when we are in one frame, it is illegal to write to the memory for another frame? If so, does that only apply to writing or is reading also illegal? Thanks for your help btw!

[JaafarRammal]

Reading non-public space is illegal as well to my knowledge

[daryllimyt]

Figured it out - it was because of these flags we included in our code to address these warnings:
Assembler messages:
Warning: no .cprestore pseudo-op used in PIC code
Commenting out .cpload and .cprestore fixed these issues