[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