Disassembly files showing no instructions being executed

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?

#include "f.h"

int main(){
    int c= fun(10,12);
    return 0;

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.