Minimal ISA dumper for amdgcn object file.
.hsatext ELF kernel symbol references amd_kernel_code_t runtime control structure (256 bytes) followed by instructions, so skip it.
Differential D16998
[AMDGPU] llvm-objdump: disassembling amdgcn object file vpykhtin on Feb 8 2016, 10:47 AM. Authored by
Details
Minimal ISA dumper for amdgcn object file. .hsatext ELF kernel symbol references amd_kernel_code_t runtime control structure (256 bytes) followed by instructions, so skip it.
Diff Detail
Event TimelineComment Actions Is there some reason why you can't parse the code object in from the AMDGPU implementation of getInstruction()? Comment Actions MCDisassembler::getInstruction is declared as follows: /// Returns the disassembly of a single instruction. /// /// \param Instr - An MCInst to populate with the contents of the /// instruction. /// \param Size - A value to populate with the size of the instruction, or /// the number of bytes consumed while attempting to decode /// an invalid instruction. /// ... virtual DecodeStatus getInstruction(MCInst &Instr, uint64_t &Size, ArrayRef<uint8_t> Bytes, uint64_t Address, raw_ostream &VStream, raw_ostream &CStream) const = 0; Its supposed to return filled MCInst as a result and return consumed bytes num. Current DisassemblyObject just passes what it consider as 'code' to the disassembler and therefore inside getInstruction we facing the following:
Comment Actions Hi, In the loop that iterates over symbols and emits them, there is already some target specific code for AARCH64. Comment Actions For now I just moved all my code to AMDGPUDisassembler library (links with llvm-objdump already) and call DisassembleHSACodeObject in the beginning of llvm-objdump's DisassembleObject if Obj->getArch() == Triple::amdgcn. It still lefts llvm-objdump slightly AMDGPU target dependent but now I think it's not worth to touch MCDisassembler interface until we know all the requirements. It's likely that we might want to disassemble HSA code object completely with AMDGPU code not depending on llvm-objdump. Comment Actions
Comment Actions
Comment Actions ".co" means CodeObject. It was created using out of llvm tree utility. It is of HSA Code Object v1.0 format which is slightly different from what AMDGPU assembler currently emitting, the main difference is - code symbol has zero size and amd_kernel_code_t (runtime control structure) and ISA could be non-adjacent. The dissasembler is supposed to accept both versions.
Comment Actions Adding quote from summary so it can be seen in notification emails: Problem: this change contains direct call for disassembleHSACodeObject from llvm-objdump which is actually located in the AMDGPU library. This is incorrect as require llvm-objdump always link with AMDGPU target. There should be a target callback somewhere that allows custom object file disassembly. One thought was to add such callback (something like disassembleObjectFile(ObjFile, OutStream)) to the MCDisassembler interface but it is a bit late because MCDisassembler is created when the target ISA specification is already known (it depends on MCSubtargetInfo) but the target ISA spec is yet to be read from the object file really. Comment Actions
Right Elf_Rel. Disassembling of this format requires different features that is currently suggested by llvm-objdump and these are really target specific. In particular we would like to print all custom directives and structures so it can be fed directly to assembler input, for example amd_kernel_code_t runtime control structure definitions. Dumping this structure without llvm-objdump->AMDGPU link dependency would require copy-paste of the target code. I'm not sure it's possible to create sufficient number of target callbacks to accomplish this. Another issue is with the HSA Code Object 1.0 format itself - zero sized kernel code symbol require to preprocess the whole .hsatext section to find start markers of every item in this section to calculate the kernel code size. This particular issue is fixed with what AMDGPU assembler currently emits but we would like disassembler could accept old files too. llvm-commits mailing list Comment Actions Made minimal possible change. Limitations:
Added test using llvm-mc | llvm-objdump check. Comment Actions I reverted it for a while, instruction bytes are printed in bigendian order on ppc despite on support::ulittle32_t usage. Need to fix. |
This should be using a endian specific type. Either llvm::support::ulittle32_t or ubig32_t.