[clang] [llvm] [Offloading] Extend OffloadBinary format to support multiple metadata entries (PR #169425)

[Yury Plyakhin via llvm-commits]

YuriPlyakhin wrote:

> No, as far as I'm aware 99% of uses of this will be through this function
> 
> ```
> Error extractOffloadFiles(MemoryBufferRef Contents,
>                           SmallVectorImpl<OffloadFile> &Binaries);
> ```
> 
> This is an owning binary of the memory, we are given the contents and just need to loop through everything. The main change here is that when we create the _reference_ version we will share the header between multiple entries. This will require some way to index into them when creating them, probably just need some method to iterate through all the entires and create binaries for them. When we create an owning binary we will just copy it over with the shared header. The header is very small, so we do not waste an amount of memory worth caring about by duplicating it. That's how I'd imagine this works at least

Not sure which of my comments exactly you are answering, but the most basic question is:
OffloadFile owns original memory buffer (whatever was read from file) - header + all entries + all images.
What is your idea about what to do with this memory buffer, when we:
1. create multiple OffloadBinary objects in extractOffloadFiles method
2. do a deep copy of OffloadFile in OffloadFile::copy method (used for example here: https://github.com/llvm/llvm-project/blob/94984d5cdbceafa786e26a9dc1f70167e574d945/clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp#L1217)

Should we use the same memory buffer in memory (with memory management) between multiple OffloadFile objects created by 1 and 2 above?
Should we create a copy of memory buffer for each OffloadFile created with 1 and 2 above?

https://github.com/llvm/llvm-project/pull/169425