[Offload] Failure to check validity of image for sm_120 architecture

[jafudev]

When compiling an offloading capable compiler with the recommended CMake cache file,

cd llvm-project
mkdir build
cd build
cmake ../llvm -G Ninja \
    -C ../offload/cmake/caches/Offload.cmake \
    -DCMAKE_BUILD_TYPE="Release" \
    -DCMAKE_INSTALL_PREFIX="/opt/llvm/llvm-project/install" \
    -DCMAKE_C_COMPILER="clang-19" \
    -DCMAKE_CXX_COMPILER="clang++-19" \
    -DLIBOMPTARGET_ENABLE_DEBUG=ON
ninja -j 24 install

running an executable containing any offloading with OMP_TARGET_OFFLOAD=mandatory ./a.out and LIBOMPTARGET_DEBUG=1 crashes with

omptarget --> Init offload library!
OMPT --> Entering connectLibrary
OMPT --> OMPT: Trying to load library libomp.so
OMPT --> OMPT: Trying to get address of connection routine ompt_libomp_connect
OMPT --> OMPT: Library connection handle = 0x70ef79559e60
OMPT --> Exiting connectLibrary
omptarget --> Loading RTLs...
omptarget --> RTLs loaded!
PluginInterface --> Failure to check validity of image 0x5651b5deed20: Invalid CUDA addressing modePluginInterface --> Failure to check validity of image 0x5651b5deed20: Invalid CUDA addressing modePluginInterface --> Failure to check validity of image 0x5651b5deed20: Invalid CUDA addressing modeomptarget --> No RTL found for image 0x00005651b5dea120!
omptarget --> Done registering entries!
omptarget --> Entering target region for device -1 with entry point 0x00005651b5dea047
omptarget --> Use default device id 0
omptarget --> Call to omp_get_num_devices returning 0
omptarget --> omp_get_num_devices() == 0 but offload is manadatory
omptarget error: Consult https://openmp.llvm.org/design/Runtimes.html for debugging options.
omptarget error: No images found compatible with the installed hardware. Segmentation fault (core dumped)

on an RTX 5070ti (sm_120 architecture).

In the related discussion on the llvm discourse (https://discourse.llvm.org/t/issues-compiling-with-offloading-support/87258/7), @jhuber6 suspects a change in the CUDA ELF ABI, see PluginInterface --> Failure to check validity of image 0x5651b5deed20: Invalid CUDA addressing mode, which is related to (https://github.com/llvm/llvm-project/blob/main/offload/plugins-nextgen/common/src/Utils/ELF.cpp#L76) is causing this issue.

[llvmbot]

@llvm/issue-subscribers-offload

Author: Jakob (jafudev)

When compiling an offloading capable compiler with the recommended CMake cache file, ``` cd llvm-project mkdir build cd build cmake ../llvm -G Ninja \ -C ../offload/cmake/caches/Offload.cmake \ -DCMAKE_BUILD_TYPE="Release" \ -DCMAKE_INSTALL_PREFIX="/opt/llvm/llvm-project/install" \ -DCMAKE_C_COMPILER="clang-19" \ -DCMAKE_CXX_COMPILER="clang++-19" \ -DLIBOMPTARGET_ENABLE_DEBUG=ON ninja -j 24 install ``` running an executable containing any offloading with `OMP_TARGET_OFFLOAD=mandatory ./a.out` and `LIBOMPTARGET_DEBUG=1` crashes with ``` omptarget --> Init offload library! OMPT --> Entering connectLibrary OMPT --> OMPT: Trying to load library libomp.so OMPT --> OMPT: Trying to get address of connection routine ompt_libomp_connect OMPT --> OMPT: Library connection handle = 0x70ef79559e60 OMPT --> Exiting connectLibrary omptarget --> Loading RTLs... omptarget --> RTLs loaded! PluginInterface --> Failure to check validity of image 0x5651b5deed20: Invalid CUDA addressing modePluginInterface --> Failure to check validity of image 0x5651b5deed20: Invalid CUDA addressing modePluginInterface --> Failure to check validity of image 0x5651b5deed20: Invalid CUDA addressing modeomptarget --> No RTL found for image 0x00005651b5dea120! omptarget --> Done registering entries! omptarget --> Entering target region for device -1 with entry point 0x00005651b5dea047 omptarget --> Use default device id 0 omptarget --> Call to omp_get_num_devices returning 0 omptarget --> omp_get_num_devices() == 0 but offload is manadatory omptarget error: Consult https://openmp.llvm.org/design/Runtimes.html for debugging options. omptarget error: No images found compatible with the installed hardware. Segmentation fault (core dumped)

on an RTX 5070ti (sm_120 architecture).

In the related discussion on the llvm discourse (https://discourse.llvm.org/t/issues-compiling-with-offloading-support/87258/7), @<!-- -->jhuber6  suspects a change in the CUDA ELF ABI, see `PluginInterface --&gt; Failure to check validity of image 0x5651b5deed20: Invalid CUDA addressing mode`, which is related to (https://github.com/llvm/llvm-project/blob/main/offload/plugins-nextgen/common/src/Utils/ELF.cpp#L76) is causing this issue.
</details>

[jhuber6]

Probably just easiest to delete that check, I'm sure something else will fail to validate in the pipeline and we don't have the time to track NVIDIA's ABI changes.

[jafudev]

I managed to track down the issues and got offloading working. There were two points which were failing:

1. Failing checks in checkMachineImpl(...)

The checks in https://github.com/llvm/llvm-project/blob/main/offload/plugins-nextgen/common/src/Utils/ELF.cpp#L76-L79 fail. Probably due to some error with the API changes as you mentioned which reports wrong values for Header.e_flags. If it helps, I get Header.e_flags=218134530 for an RTX 5070 Ti.
The temporary fix is to just comment these checks out.

2. Wrongly reported platform flags in getPlatformFlags()

The platform flags for are not correct in https://github.com/llvm/llvm-project/blob/main/offload/plugins-nextgen/cuda/src/rtl.cpp#L1445. Here I also get the same flag value as above ElfOrErr->getPlatformFlags()=218134530. When the flag is evaluated with the ELF::EF_CUDA_SM=255U mask you get the result SM=2 Thus the method returns false as the comparison to the CUDA architecture later will fail (the CUDA architecture is reported as Major=12 and Minor=0 which corresponds to sm_120. I would expect to get SM=120 when reading the comment one line above.
The temporary fix here is to just set SM to 120 when it is 2.

Conclusion

When applying both fixes as described above I can run my programs with offloading on the RTX 5070 Ti with sm_120.
Though to make a clean fix you would probably need to look into the ELF ABI as you mentioned before, which I don't know how to do.

Probably just easiest to delete that check, I'm sure something else will fail to validate in the pipeline and we don't have the time to track NVIDIA's ABI changes.

[jhuber6]

Right, so guess we do need to figure out whatever NVIDIA did to represent the SMs greater than 100 since we need it for compatibility checks.

[hakostra]

Great work, @jafudev

I hope someone with deeper Nvidia knowledge can pick up the unresolved tails here and make the sm_120 work properly...