Option -aC produces disassembly that does not create a full binary

[Lolliedieb]

Hello,

I have got a strange problem with the disassembler.
The kernel I created was build initially by the build in compiler of the driver (amdgpu-pro 18.30, -t parameter is -t 267103 on a RX 580). If I disassemble the kernel with clrxdisasm -a -t 267103 the created assembly can afterwards problem free converted back with clrxasm into a binary that I can load and execute (and also the changes I want to do in asm so far work fine).

But if I do the same with -aC it seems some part of the configuration is not completely translated. The kernel then builds again and also the driver succeeds to load it, but the code in the kernel called just does not execute.

It would be nice to change the configuration though (and I have to admit I rather need the hsa config -aCHL). What I can say is that the resulting binary also does not have the same size (96.5 kbyte vs 97.x), so there seems to be an actual difference.

Kind regards

[matszpk]

By default, a clrxdisasm with options "-aC" print configuration in a human-readable form. This form does not include entire the HSA kernel configuration. The '-aCHL" dumps configuration in HSA kernel form (-H option) and in HSA layout (option -L). In some cases, due to kernel alignment/size or (more important) or missing some additional data (enough unlikely) the standard human-readable form can fail. However a options '-aC' should dump all needed data's to assemble correct binary, if some data's will be missed, then a CLRXDisasm would have some bugs. If you think, that it is enough important (due to strange kernel execution), you can send me some sample a disassembler outputs and generated binaries from that outputs. Some complex cases with samplers and other additional data's has been poorly tested by me, due to small amount of the time.

[Melirius]

I can provide an example of such behaviour, if you are interested.

[Lolliedieb]

It might be that today I found out what is going on - with an other Kernel though.

If I have a kernel that does have globally shared data in .globaldata that is then later read by the kernel, then the kernel - depending on the compiler might do some tricky address calculation - e.g. just seen in disassembly:

/*000000000134: be841c00 */ s_getpc_b64 s[4:5]
/000000000138: 8004ff04 fffff508/ s_add_u32 s4, s4, 0xfffff508
/000000000140: 8205ff05 ffffffff/ s_addc_u32 s5, s5, lit(-1)

The code obviously fetches the program counter and then subtracts 2808 bytes which is a position thats clearly before the program started. It seems that the disassembler just taking this constants without resolving to the label / the placement of the data after recompiling with the assembler might be different and the address may not fit any more. In some cases the address
calculation then points even to a address thats invalid causing the card to lock up.

Is there any way to resolve to the right address?
I tried doing something like inserting
s_mov_b64 s[4:5], .gdata

But then the compiler complains about "Error: Expression must be absolute!" ... well but I do not know the absolute offset to my data section :/

Edit: if it helps: kernel is in llvm10 format for rocm 3.5.