I’m using espresssif/llvm-project repo for my LLVM compiler build to generate code for xtensa specific architecture. However I’m facing issues running the executable using xt-clang command xt-run. Observing the .dis file for my code it seems that there are no instructions in the main, hence it is not executing. Does anyone know a quick fix?
//main.c//
#include "f.h"
int main(){
int c= fun(10,12);
return 0;
}
//f.h//
int fun(int a,int b){
int c= a+b;
return c;
}```
Can you reproduce the behaviour using another target and upstream llvm? If it does not, this may be best asked over on the fork’s issues.
In general, the call to fun
is liable to be optimised out above -O0
. E.g. Compiler Explorer. Adding volatile
to c
avoids that just for testing purposes.
If you mean there are literally no instructions in main
, then that’s something else. On Arm you’d at worst have a single ret
. I don’t know about espressif.
Thanks for the idea just tried it out.
The code executes fine when targeting other architectures and I have asked it on the fork’s issues but waiting for a response.
This is the main section for the .dis file using xt-clang:
80000578 <main>:
80000578: 006136 entry a1, 48
8000057b: 012d mov.n a2, a1
8000057d: 1129 s32i.n a2, a1, 4
8000057f: aa0c movi.n a10, 10
80000581: cb0c movi.n a11, 12
80000583: 0000a5 call8 8000058c <_Z3funii>
80000586: 01a9 s32i.n a10, a1, 0
80000588: 020c movi.n a2, 0
8000058a: f01d retw.n
This is the same using the llvm fork:
80000240 <main>:
80000240: 7d006136 29020c01 0caa0c17 ff9881cb 6a.}...)........
80000250: a90008e0 00f01d07 ........
I was wondering if this is an issue related to the linker as the .asm files seem fine.
It might be, because I see the entry
and retw.n
are there in the second output, but seemingly shifted a few bytes. Maybe this is normal for that target, but it could throw off some tools that are expecting instructions to be aligned and not display correctly in a disassembler.
You could try bringing fun
into the same file as main
, then checking the produced object file pre-link. Might back up your suspicions.
Unfortunately it doesn’t seem to be a linking issue as I’m getting the same output. It must be a fork related issue.