esp-llvm icon indicating copy to clipboard operation
esp-llvm copied to clipboard

Calling Convention not respected

Open federeghe opened this issue 9 years ago • 7 comments

Hi! I think there is a problem in riscv-trunk when compiled with -O1 option. I attached an example in c and the generated assembly.

I compile with:

/.../clang -O1 -target riscv -mriscv=RV32I test.c -S -o test.S /.../riscv32-unknown-elf-gcc test.S -o test.o

I think that the last jalr (line 42) jumps to a wrong address.

test.zip

federeghe avatar Jul 08 '16 10:07 federeghe

How so? That's your last printf call, and it's targetting printf; compute doesn't clobber x12

sorear avatar Jul 08 '16 14:07 sorear

Is it possible that x12 is overwritten by the printf itself? The address in x12 is calculated before the first printf, but it isn't recalculated before the subsequent call to printf, so x12 may contain invalid address if printf uses it.

federeghe avatar Jul 11 '16 21:07 federeghe

You're probably right yeah. If x12 is caller-saved, then main is failing to save it around the printf, and if it's callee-saved, then main is failing to save it. Not sure which version of the calling convention LLVM presently implements.

sorear avatar Jul 16 '16 03:07 sorear

I think it is the last calling convention of RISCV implemented in f4c04eec45a3cf50fd709435cea60ab58c5b95e9. In fact, x12 is caller-saved but it seems that the backend interprets it as callee-saved.

I'm trying to figure out where is the error in the code, but I'm not an expert of LLVM, so it's quite difficult.

federeghe avatar Aug 04 '16 16:08 federeghe

I had the same problem.
I found a commit (ce8ac4e) in a different branch (caller-saved-fix) that seems to fix the bug that you and I had. Not sure why the additional spill slots were added (lib/Target/RISCV/RISCVFrameLowering.cpp) but the rest makes sense.

I don't know also why this branch (caller-saved-fix) was not merged with the riscv-trunk branch.

sapostolakis avatar Jan 09 '17 20:01 sapostolakis

Note, this repository does not have an active maintainer.

sorear avatar Jan 09 '17 20:01 sorear

I came here to find a solution for a bug which I found on dhrystone.

...
    94    strcpy (Ptr_Glob->variant.var_1.Str_Comp, 
    95            "DHRYSTONE PROGRAM, SOME STRING");
    96    strcpy (Str_1_Loc, "DHRYSTONE PROGRAM, 1'ST STRING");
...

This lines were compiled to; (strcpy(dst, src) is converted to memcpy(dst, src, size))

...
204000e2:       20404337                lui     t1,0x20404
204000e6:       7f030593                addi    a1,t1,2032 # 204047f0 <__clzsi2+0x66>
204000ea:       01028513                addi    a0,t0,16
204000ee:       467d                    li      a2,31 // the 3rd arg, size
204000f0:       386010ef                jal     ra,20401476 <memcpy> // a2 is overwritten by the callee
204000f4:       204052b7                lui     t0,0x20405
204000f8:       80f28593                addi    a1,t0,-2033 # 2040480f <__clzsi2+0x85>
204000fc:       06c40513                addi    a0,s0,108

20400100 <Ltmp15>:
20400100:       376010ef                jal     ra,20401476 <memcpy> // a2 should be 31
...

The commit (ce8ac4e) fixed this issue.

Note, this repository does not have an active maintainer.

This is a bad news...

hirooih avatar Mar 06 '17 15:03 hirooih