This is an archive of the discontinued LLVM Phabricator instance.

[AMDGPU] llvm-objdump: Skip amd_kernel_code_t only at the begining of kernel symbol.
ClosedPublic

Authored by SamWot on Jul 4 2016, 3:16 AM.

Details

Summary

This change fix bug in AMDGPU disassembly. Previously, presence of symbols other than kernel symbols caused objdump to skip begining of those symbols.

Diff Detail

Event Timeline

SamWot updated this revision to Diff 62659.Jul 4 2016, 3:16 AM
SamWot retitled this revision from to [AMDGPU] llvm-objdump: Skip amd_kernel_code_t only at the begining of kernel symbol..
SamWot updated this object.
SamWot added a subscriber: arsenm.
SamWot added a project: Restricted Project.Jul 4 2016, 3:17 AM
Bigcheese edited edge metadata.Jul 4 2016, 9:37 AM

I find it odd that we need all this machinery just to keep track of the type of a symbol. Why not just make `AllSymbols``` map to a SymbolRef an extract it from there?

SamWot added a comment.Jul 5 2016, 2:04 AM

I find it odd that we need all this machinery just to keep track of the type of a symbol. Why not just make `AllSymbols``` map to a SymbolRef an extract it from there?

Problem here is that SymbolRef::Type isn't same as ELF type. SymbolRef::Type contains only some common types between ELF, COFF and Mach-O file formats. So SymbolRef::Type does not content types that AMDGPU uses (STT_AMDGPU_HSA_KERNEL).

I find it odd that we need all this machinery just to keep track of the type of a symbol. Why not just make `AllSymbols``` map to a SymbolRef an extract it from there?

Problem here is that SymbolRef::Type isn't same as ELF type. SymbolRef::Type contains only some common types between ELF, COFF and Mach-O file formats. So SymbolRef::Type does not content types that AMDGPU uses (STT_AMDGPU_HSA_KERNEL).

Yes, but I'm pretty sure you can go from a SymbolRef to a Elf_Sym *.

SamWot added a comment.Jul 6 2016, 3:41 AM

I find it odd that we need all this machinery just to keep track of the type of a symbol. Why not just make `AllSymbols``` map to a SymbolRef an extract it from there?

Problem here is that SymbolRef::Type isn't same as ELF type. SymbolRef::Type contains only some common types between ELF, COFF and Mach-O file formats. So SymbolRef::Type does not content types that AMDGPU uses (STT_AMDGPU_HSA_KERNEL).

Yes, but I'm pretty sure you can go from a SymbolRef to a Elf_Sym *.

Yes, I think this solution might be better, but it will include rewriting big part of DisassembleObject() that will involve changes in code for other back-ends.
I'm not sure that my change is worth such changes. But If you think it's worth then I can do it.

I find it odd that we need all this machinery just to keep track of the type of a symbol. Why not just make `AllSymbols``` map to a SymbolRef an extract it from there?

Problem here is that SymbolRef::Type isn't same as ELF type. SymbolRef::Type contains only some common types between ELF, COFF and Mach-O file formats. So SymbolRef::Type does not content types that AMDGPU uses (STT_AMDGPU_HSA_KERNEL).

Yes, but I'm pretty sure you can go from a SymbolRef to a Elf_Sym *.

Yes, I think this solution might be better, but it will include rewriting big part of DisassembleObject() that will involve changes in code for other back-ends.
I'm not sure that my change is worth such changes. But If you think it's worth then I can do it.

Hi Michael,
What do you think about this changes? Are they really needed?
Actually, I took another look at DisassembleObject(). Changing AllSymbols map to SymbolRef would require even more changes than I thought earlier. Problem is with COFFObjectFile. It have export table and its contents (class ExportDirectoryEntryRef) are currently stored inside AllSymbols. But if we want to change AllSymbols then we would not be able to store ExportDirectoryEntryRef in AllSymbols. To solve this would requier either some greater machinery or changes in COFFObjectFile architecture.

vpykhtin edited edge metadata.Jul 28 2016, 7:18 AM

I find it odd that we need all this machinery just to keep track of the type of a symbol. Why not just make `AllSymbols``` map to a SymbolRef an extract it from there?

Problem here is that SymbolRef::Type isn't same as ELF type. SymbolRef::Type contains only some common types between ELF, COFF and Mach-O file formats. So SymbolRef::Type does not content types that AMDGPU uses (STT_AMDGPU_HSA_KERNEL).

Yes, but I'm pretty sure you can go from a SymbolRef to a Elf_Sym *.

For what I see "AllSymbols" is a level of indirection to be able to unify symbol name processing with COFF export table, which contains actually no symbols. One of the decision can be to add some generic "type" field to "AllSymbols" and initialize it where applicable removing the need in additional map machinery.

I find it odd that we need all this machinery just to keep track of the type of a symbol. Why not just make `AllSymbols``` map to a SymbolRef an extract it from there?

Problem here is that SymbolRef::Type isn't same as ELF type. SymbolRef::Type contains only some common types between ELF, COFF and Mach-O file formats. So SymbolRef::Type does not content types that AMDGPU uses (STT_AMDGPU_HSA_KERNEL).

Yes, but I'm pretty sure you can go from a SymbolRef to a Elf_Sym *.

For what I see "AllSymbols" is a level of indirection to be able to unify symbol name processing with COFF export table, which contains actually no symbols. One of the decision can be to add some generic "type" field to "AllSymbols" and initialize it where applicable removing the need in additional map machinery.

I thought of this but decided that different map whould be better for several reasons:

  • It is better if code needed only for AMDGPU would be separeted from general code used by everybody.
  • Another thing is that adding another field to AllSymbols would increase it's size for all back-end. Even for those that don't use it.
SamWot updated this revision to Diff 66107.Jul 29 2016, 4:15 AM
SamWot edited edge metadata.

Removed extra map. Added symbol type to AllSymbols.

Bigcheese accepted this revision.Aug 17 2016, 2:07 AM
Bigcheese edited edge metadata.

lgtm. Sorry for taking so long on the review.

This revision is now accepted and ready to land.Aug 17 2016, 2:07 AM
This revision was automatically updated to reflect the committed changes.