[llvm] [Offloading] Extend OffloadBinary format to support multiple metadata entries (PR #169425)
Yury Plyakhin via llvm-commits
llvm-commits at lists.llvm.org
Tue Nov 25 09:08:17 PST 2025
================
@@ -109,9 +109,12 @@ class OffloadBinary : public Binary {
struct Header {
uint8_t Magic[4] = {0x10, 0xFF, 0x10, 0xAD}; // 0x10FF10AD magic bytes.
uint32_t Version = OffloadBinary::Version; // Version identifier.
- uint64_t Size; // Size in bytes of this entire binary.
- uint64_t EntryOffset; // Offset of the metadata entry in bytes.
- uint64_t EntrySize; // Size of the metadata entry in bytes.
+ uint64_t Size; // Size in bytes of this entire binary.
+ uint64_t EntriesCount; // Number of metadata entries in the binary.
+ uint64_t EntriesOffset; // Offset in bytes to the start of entries block.
+ uint64_t EntriesSize; // Size of the entries block in bytes.
----------------
YuriPlyakhin wrote:
I think we need either `EntriesCount` or `EntriesSize`, so we know how much entries we need to read or where to stop.
Currently, `OffloadBinary` keeps in this order: `Header`, `Entry`, N * `StringEntry`, N * [`Key`, `Value`], `Image`.
With multiple entries support we would have: `Header`, M * `Entry`, N * `StringEntry`, N * [`Key`, `Value`], M * `Image`.
So, we cannot read entries until we exceed the total binary size.
Single `Entry` size is always the same now: `sizeof(Entry)`, and it is currently used only to verify that binary is correct.
Image size is stored inside `Entry` now.
Hence, I think to keep the change minimal, we can just change one thing: EntrySize -> EntriesSize, so instead of 'sizeof(Entry)` it would keep the total size of all entries.
https://github.com/llvm/llvm-project/pull/169425
More information about the llvm-commits
mailing list