From: Pekka J. <pek...@tu...> - 2011-12-19 10:36:52
|
On 12/19/2011 12:18 PM, Carlos Sánchez de La Lama wrote: > I think we can reuse AMD one (just uses ELF sections for different > binaries) as it is well specified. IIRC, the AMD's ELF files store the LLVM bitcode and the AMD-IL (both IRs), not the final binary, right? The OpenCL API for fetching and loading the program binaries is multi-device. Thus the format should not be tied to an architecture as it can contain the same kernels compiled for multiple devices. I'm not sure if the ELF provides some benefits for this scenario. We need basically a format that stores multiple independent (sometimes ELF?) binaries for the compiled program(s) and the LLVM bitcode as a separate one. The compiled programs should be quickly loadable to the dynamic linker, preferably without extracting them first to a separate file. Can ELF support this nicely? The stored binaries (same kernels compiled for multiple dimensions) might contain clashing symbols, AFAIU so they should be stored as "binary blob sections" in ELF, not as "program sections" with linkage/relocation info? You know ELF better than I do... What about FatELF? http://en.wikipedia.org/wiki/Executable_and_Linkable_Format#FatELF:_Universal_Binaries_for_Linux Let's see... -- Pekka |