[offload] Redesign the ELF format for device-side binaries.

[StevenYangCC]

Redesign the ELF format for device-side binaries.
The original binary format is not suitable for device-side binaries.
For example:
Provide a callgraph section to enable binary optimizations at link time, as well as support for lazy loading.
Provide a prototype section to support function pointers.
Provide a section for recording metadata for each function, such as register kind, register number, stack size, etc. This metadata should be extensible, as different architectures may require different metadata, and the attributes of kernel functions and regular functions may also vary.
Moderately reference the CUDA cubin format for inspiration.

[llvmbot]

@llvm/issue-subscribers-offload

Author: None (StevenYangCC)

Redesign the ELF format for device-side binaries. The original binary format is not suitable for device-side binaries. For example: Provide a callgraph section to enable binary optimizations at link time, as well as support for lazy loading. Provide a prototype section to support function pointers. Provide a section for recording metadata for each function, such as register kind, register number, stack size, etc. This metadata should be extensible, as different architectures may require different metadata, and the attributes of kernel functions and regular functions may also vary. Moderately reference the CUDA cubin format for inspiration.

[jhuber6]

I also do not understand this issue. Most of what you're describing is handled by the GPU runtime's loader, which is not something we have access to from offload/. We already have metadata for things like this in AMDGPU at least, unless you're talking about using that information with a call graph to generate the launch packet metadata?

[Artem-B]

@StevenYangCC if you could elaborate on the issue(s) that prompt this request, it would be very helpful to figure out how those issues should be addressed.

[StevenYangCC]

The ELF format generated by LLVM compilation is very rigid and cannot be flexibly handled on different architectures and does not meet the needs of heterogeneous computing architectures.

[jhuber6]

The ELF format generated by LLVM compilation is very rigid and cannot be flexibly handled on different architectures and does not meet the needs of heterogeneous computing architectures.

This is completely vague so I'm just going to close this.

[StevenYangCC]

@jhuber6 What I mean is that the device-side ELF format should be redesigned instead of using the same ELF format as the host-side, since the needs of the two are not consistent. For example, the metadata in the file in the device side of the ELF for AMDGPUs is currently a big, overarching structure, and a lot of unneeded attributes take up space as well. We can design a binary ELF format that is applicable to the device side of all heterogeneous architectures, and each architecture can flexibly add sections, symbols, or attributes.

[jhuber6]

@jhuber6 What I mean is that the device-side ELF format should be redesigned instead of using the same ELF format as the host-side, since the needs of the two are not consistent. For example, the metadata in the file in the device side of the ELF for AMDGPUs is currently a big, overarching structure, and a lot of unneeded attributes take up space as well. We can design a binary ELF format that is applicable to the device side of all heterogeneous architectures, and each architecture can flexibly add sections, symbols, or attributes.

I do not know what this means, feel free to write up a design document and contribute patches.

[StevenYangCC]

@jhuber6 You can express your doubts in detail and I will try my best to express them clearly.

[Artem-B]

Moderately reference the CUDA cubin format for inspiration.

That request and responses read like a chat with an LLM. I wonder if we're being curl'ed here? https://arstechnica.com/gadgets/2025/05/open-source-project-curl-is-sick-of-users-submitting-ai-slop-vulnerabilities/