target porting : objdump is not giving proper registers.

Hi,
we have seen proper register numbers when we have generated assembly files through clang but
when we generated dump files from object file then we didn’t see expected register numbers.

Note : all registers are replaced with R0

Disassembly of section .text:

00000000 :
0: 3000ffcc addik r0, r0, -52
4: f8000000 swi r0, r0, 0
8: 10000000 addk r0, r0, r0
c: f800002c swi r0, r0, 44
10: 3000000a addik r0, r0, 10
14: f8000028 swi r0, r0, 40
18: 3000000f addik r0, r0, 15
1c: f8000024 swi r0, r0, 36
20: e8000028 lwi r0, r0, 40
24: 6000000f muli r0, r0, 15
28: f8000020 swi r0, r0, 32
2c: 10000000 addk r0, r0, r0
30: e8000000 lwi r0, r0, 0
34: b60f0008 rtsd r15, 8
38: 30000034 addik r0, r0, 52

I am not able to find where it went wrong.could you help me with some notes.

Thanks,
Mahesh B

Hi Mahesh,

we have seen proper register numbers when we have generated assembly files
through clang but when we generated dump files from object file then we didn't see expected
register numbers.

I assume this is a backend you're writing? Those encodings have a lot
of 0s in them, so I'm guessing the object file is what's wrong rather
than the dumper.

Have you made sure you have fields in your instructions whose names
match the registers in the (outs) and (ins) and get assigned to the
"Inst" bitfield? That's how TableGen knows where to encode each
register.

You should look for calls to getMachineOpValue in
build/lib/Target/XYZ/XYZGenMCCodeEmitter.inc, both in the source and
with a debugger to make sure it's actually being called and doing what
you expect.

Cheers.

Tim.

Hi Tim,

Thanks for your observations.It seems I have missed adding encoding values for registers.

Thanks,

Mahesh B