[Comgr][hotswap] Add code-object metadata parsing

[tgymnich]

Adds the ELF/MsgPack metadata parser that the rest of the raiser pipeline
depends on. Public surface is extractTextSection, listKernelNames,
extractKernelMeta, findKernelSymbolOffset, and detectIsaFromElf.

No MC stack, no disassembler, no opcode canonicalisation yet — those land
in subsequent commits. The kernel-descriptor fields on KernelMeta (kernel
code properties, kernarg preload, compute_pgm_rsrc1/2) are populated here
so later layers (UserSgprLayout, kernarg layout) have the metadata they
expect; the raiser itself does not consume them yet.

Includes a small focused gtest covering the empty-input and malformed-ELF
guards on the public API.

Co-Authored-By: Claude Opus 4.7 (1M context) noreply@anthropic.com

[z1-cciauto]

PSDB Link: https://compiler-ci.amd.com/job/compiler-psdb-amd-staging/5771

[tgymnich]

Warning

Stacked PR

1. [Comgr][hotswap] Add bare-bones hotswap transpiler scaffolding #2438
2. [Comgr][hotswap] Add code-object metadata parsing #2437 <----
3. [Comgr][hotswap] Add AMDGPU MC state setup #2439
4. [Comgr][hotswap] Add DecodedInst + basic kernel decoder #2517
5. [Comgr][hotswap] Add wave projection + ISA profile + abi/wave-mask docs #2518
6. [Comgr][hotswap] Add raise_failure + RaiseContext + register file #2551
7. [Comgr][hotswap] Add raise_cli + lit harness for hotswap-raise fixtures #2552
8. [Comgr][hotswap] Add SOPP + SOPC handlers #2553

[z1-cciauto]

PSDB Link: https://compiler-ci.amd.com/job/compiler-psdb-amd-staging/5773

[lamb-j]

Thanks for putting this up. Two main pieces of feedback, both around the AGENT_CONVENTIONS "Comgr first, LLVM second, custom never" rule. The below is obv Claude's thoughts. But in general, we can beef up the existing Comgr metadata API implementations if we need to support Hotswap's needs. I think that could benefit both "sub-projects".

---

Reuse existing Comgr metadata APIs

amd/comgr/src/comgr-metadata.{h,cpp} already does most of what this PR adds, and reusing it would also fix a few correctness issues:

This PR	Existing Comgr API
extractKernelMeta / listKernelNames (manual note walk + MsgPack parse)	getMetadataRoot → getElfMetadataRoot<ELFT> (comgr-metadata.cpp:190, 254)
detectIsaFromElf (e_machine → "gfx1250")	getElfIsaName → getElfIsaNameFromElfHeader<ELFT> (comgr-metadata.cpp:350, 410)
findKernelSymbolOffset symbol walk	amd_comgr_iterate_symbols + amd_comgr_symbol_get_info, or the internal helpers in comgr-symbol.cpp

Switching to getElfMetadataRoot also fixes three latent bugs in the hand-rolled walker:

1. Misses program-header notes. getElfMetadataRoot walks PT_NOTE program headers first, then SHT_NOTE sections. This PR only walks sections — fully-linked AMDGPU code objects often carry notes via program headers only, so they'd come back with zero kernels.
2. Misses name=="AMD" / NT_AMD_HSA_METADATA (older YAML) and PAL metadata. The hand-rolled check is hardcoded to name=="AMDGPU" && type==32. processNote + mergeNoteRecords handle all three vendor-name/type combinations.
3. Bails on anything that isn't ELF64LE. getElfObjectFileBase dispatches across ELF32LE / ELF64LE / ELF32BE / ELF64BE.

detectIsaFromElf similarly returns a bare "gfx1250" and drops OS ABI, ABI version, and the sramecc/xnack feature bits. getElfIsaNameFromElfHeader already produces the canonical amdgcn-amd-amdhsa--gfx1250:sramecc+:xnack- triple — depending on what the raiser does downstream with the ISA string, dropping the feature bits is likely a problem.

The Comgr internal helpers take DataObject* / DataMeta*, which a standalone transpiler library doesn't have. The minor update I'd propose is lifting getElfMetadataRoot and getElfIsaNameFromElfHeader to a MemoryBufferRef/ArrayRef<uint8_t> overload (the templates already take ELFObjectFile<ELFT>*, so the wrapping is thin), with the existing DataObject* entry points becoming one-line forwarders. Happy to do that update separately if it helps unblock this.

The one piece that's genuinely new is readKernelDescriptorBytes — the 64-byte KD blob isn't surfaced via MsgPack and the raiser legitimately needs it. Even there, the symbol-lookup half should go through amd_comgr_iterate_symbols / a comgr-symbol.cpp helper; only the "reinterpret the bytes as kernel_descriptor_t" part is net-new.

Reuse existing LLVM facilities

A few hand-rolled bits that already exist in llvm/:

• readFile() → llvm::MemoryBuffer::getFile (handles error, empty file, mmap)
• readU32 / readU16 (host-endian memcpy) → llvm::support::endian::read32le / read16le (llvm/Support/Endian.h)
• Manual ELF note iteration → llvm::object::ELFFile::notes() (Elf_Note_Iterator) — this also removes the ~50-line duplication between listKernelNames and extractKernelMeta
• if (shdr.sh_type != 7) // SHT_NOTE → llvm::ELF::SHT_NOTE
• if (type == 32 ...) → llvm::ELF::NT_AMDGPU_METADATA
• 64 (KD size) → sizeof(llvm::amdhsa::kernel_descriptor_t), and ideally read fields via reinterpret_cast<kernel_descriptor_t*> rather than readU32(... + COMPUTE_PGM_RSRC1_OFFSET)

Most of these collapse into the Comgr reuse above (the note iteration disappears entirely if you go through getElfMetadataRoot).

[chinmaydd]

We really really really need to pull out common functionality that is shared between the transpiler and the translator into a singular module. We will have to suffer from a lot of code duplication later otherwise.

[ftynse]

Likely needs to be redirected beyond the PR author, but why this is not just "part of LLVM project". If there is intention to contribute this to LLVM, are we we expecting to have to update all files?

[ftynse]

The overall concern is the error flow. This code mostly just dumps stuff to errs without telling errors and warnings apart, sometimes suppressing things later. There is also no consistent error propagation mechanism, sometimes it's random booleans (LLVM had a huge discussion on whether true because error or success), sometimes it's empty containers (which could be valid!), sometimes it's some intermediate field.

[ftynse]

Added error handling here 960a69e @tgymnich feel free to pull in

[ftynse]

more in f68dd49, but irrelevant for the current PR