Closed stuartarchibald closed 1 year ago
scott-linder
commented
5 years ago This is a known bug in the loader which we are working on. You can workaround it by passing "-mno-code-object-v3" in the option string during compilation. We hope to have a fix by the end of next week.
stuartarchibald
commented
5 years ago Thanks for this, I've added that line in, seems like it makes compilation succeed but the relocatables generated either don't contain the metadata expected/declared by the spec.
For a -v3 style object I can programmatically obtain that the root is a map and has size 1. The Version node is the only thing in the map and can be parsed as two string nodes 1 and 0.
For a +v3 style object I can programmatically obtain that the root is a map and has size 2, it would appear both amdhsa.version and amdhsa.kernels are in there, however, due to the above bug I cannot really test this in practice (at present, I've just compiled a +v3 DSO and shoehorned the bytes in at the appropriate location.
lamb-j
commented
1 year ago This should be fixed in recent releases. If anyone is still hitting an issue with this please comment and I can reopen!
I'm afraid this is going to be a bit vague. Essentially, I had the
comgrtooling working as a compilation pipeline for Numba. I was forced to upgrade to ROCm 2.0 following updates to the base Centos 7 OS which rendered the ROCm 1.9.x release bizarrely broken (absolutely no call to HSA* worked, and the/opt/rocm/bintools showed strange things). Having now fixed up the Numba code against thecomgrthat shipped with ROCm 2.0, the compilation withcomgrsucceeds but then does:when a load of the executable object is attempted.
Further, the command line tools and libraries for doing compilation shipped in Numba's
rocmtoolspackage continue to work (despite being 1.9.x toolchain based). This suggests the drivers/runtime etc are still working as expected and it is indeed a problem with the ELF?Any suggestions as to likely causes of the problem would be welcomed. Thanks.