Remove comgr delay-load stub; statically link LLVM into comgr

[stellaraccident]

Summary

• Remove the amd-comgr-stub delay-load/namespace-isolation mechanism
• Have comgr statically link LLVM/Clang/LLD component libraries instead
• LLVM symbols are hidden by comgr's existing version script (local: *;) and -fvisibility=hidden
• Add patch 0010 with a COMGR_STATIC_LLVM option to comgr's CMakeLists.txt (4-line upstream change, default OFF)

The delay-load stub used dlmopen for linker namespace isolation but glibc namespace support is insufficient across supported distros. TheRock already builds both libLLVM.so and individual PIC-enabled static .a component libraries (BUILD_SHARED_LIBS=OFF + LLVM_BUILD_LLVM_DYLIB=ON), so comgr can link the static libs while tools continue using libLLVM.so.

Test plan

• CI configure + build passes
• nm -D libamd_comgr.so | grep -c LLVM returns 0 (LLVM symbols hidden)
• ldd libamd_comgr.so | grep -c libLLVM returns 0 (no runtime dependency)
• nm -D libamd_comgr.so | grep amd_comgr_ shows all API symbols
• ASAN/TSAN presets still configure correctly (no longer need delay-load workaround)

Fixes #3729

🤖 Generated with Claude Code

[stellaraccident]

@b-sumner Will let the CI run then pull artifacts and verify symbols/sizes. If looks ok, you can land the LLVM patch and/or we can carry it locally in therock and let you do that after.

[ScottTodd]

@b-sumner Will let the CI run then pull artifacts and verify symbols/sizes. If looks ok, you can land the LLVM patch and/or we can carry it locally in therock and let you do that after.

I'm approving the new patch addition for CODEOWNERS given compiler team engagement on this topic and the delayed cadence at which compiler changes are pulled in via submodules compared to rocm-libraries and rocm-systems. See more considerations on using patch files at https://github.com/ROCm/TheRock/tree/main/patches.

I have not done a detailed review of the other parts of this change.

[lamb-j]

I can help get the patch applied in Comgr to minimize the patch file's lifespan.

[lamb-j]

Do we want to remove the delay loading mechanism entirely? Or just disable it for ASAN builds?

The ability to dynamically link LLVM was viewed as desirable for a long time, and the delay loading approach seemed to allow us to do it without hitting the previous issues with symbol collisions with LLVM global command line options.

I do remember one of the main motivations for the DYLIB was to allow the tools to dynamically link; looks like with this change we can still do that, while statically linking Comgr.

If everyone is OK with moving back to statically linking LLVM into Comgr (and the increase in amd_comgr.so size), I don't object.

@kzhuravl @searlmc1

[stellaraccident]

Do we want to remove the delay loading mechanism entirely? Or just disable it for ASAN builds?

The ability to dynamically link LLVM was viewed as desirable for a long time, and the delay loading approach seemed to allow us to do it without hitting the previous issues with symbol collisions with LLVM global command line options.

I do remember one of the main motivations for the DYLIB was to allow the tools to dynamically link; looks like with this change we can still do that, while statically linking Comgr.

If everyone is OK with moving back to statically linking LLVM into Comgr (and the increase in amd_comgr.so size), I don't object.

@kzhuravl @searlmc1

I couldn't actually make the namespacing work. I had it working on newer glibc's but had no end of trouble elsewhere and basically concluded it is not feasible this decade to do what I was trying.

I think dylib for the tools and static for comgr is the best we can do at this point without some fairly serious surgery. When @b-sumner told me this would require even more modification of the mechanism in order to support asan symbolization properly, that pushed me over the edge.

I'd rather just take it out vs leave it in to rot. It is like an hour of work to bring it back if we ever want it, but I suspect we end up taking a different approach to isolation of we we need to go back there. Easier to consider that from a clean slate.

[stellaraccident]

Do we want to remove the delay loading mechanism entirely? Or just disable it for ASAN builds?
The ability to dynamically link LLVM was viewed as desirable for a long time, and the delay loading approach seemed to allow us to do it without hitting the previous issues with symbol collisions with LLVM global command line options.
I do remember one of the main motivations for the DYLIB was to allow the tools to dynamically link; looks like with this change we can still do that, while statically linking Comgr.
If everyone is OK with moving back to statically linking LLVM into Comgr (and the increase in amd_comgr.so size), I don't object.
@kzhuravl @searlmc1

I couldn't actually make the namespacing work. I had it working on newer glibc's but had no end of trouble elsewhere and basically concluded it is not feasible this decade to do what I was trying.

I think dylib for the tools and static for comgr is the best we can do at this point without some fairly serious surgery. When @b-sumner told me this would require even more modification of the mechanism in order to support asan symbolization properly, that pushed me over the edge.

I'd rather just take it out vs leave it in to rot. It is like an hour of work to bring it back if we ever want it, but I suspect we end up taking a different approach to isolation of we we need to go back there. Easier to consider that from a clean slate.

Let's land the patch that enables the static build option in comgr regardless. I can prepare another PR tomorrow that leaves it in and just disables delay loading for comgr, and then we can decide. Dynamic linking is attractive but it still does have interposition issues that can't be solved without the linker namespaces I couldn't get to work. We fixed the biggest ones in other public codebases that were conflicting, but I do still get reports of issues with the dynamic linking from customers and was considering just taking the size hit and getting back to a stable place before the asan issue came up

[lamb-j]

I'd rather just take it out vs leave it in to rot. It is like an hour of work to bring it back if we ever want it, but I suspect we end up taking a different approach to isolation of we we need to go back there. Easier to consider that from a clean slate.

I support this route. We'll have a reference for re-adding in the git history. And we can create a separate branch with the delay-load if we want it for experimentation.

reports of issues with the dynamic linking from customers

If you have any of these reports handy, I'd be interested in taking a look and creating a Jira. We have some new people looking at long-term projects, including global option handling with LLVM, that could help investigate.

Filed ROCm/llvm-project#1640. It should land in the w10 or w11 compiler weekly branch, so we can remove the patch once the amd-llvm submodule pointer is updated to that (likely 2-3 weeks from now)

[stellaraccident]

I'm going to land this on Monday. I don't want to make an infra change like this at 4:30pm on a Friday.

[stellaraccident]

I'd rather just take it out vs leave it in to rot. It is like an hour of work to bring it back if we ever want it, but I suspect we end up taking a different approach to isolation of we we need to go back there. Easier to consider that from a clean slate.

I support this route. We'll have a reference for re-adding in the git history. And we can create a separate branch with the delay-load if we want it for experimentation.

reports of issues with the dynamic linking from customers

If you have any of these reports handy, I'd be interested in taking a look and creating a Jira. We have some new people looking at long-term projects, including global option handling with LLVM, that could help investigate.

Filed ROCm/llvm-project#1640. It should land in the w10 or w11 compiler weekly branch, so we can remove the patch once the amd-llvm submodule pointer is updated to that (likely 2-3 weeks from now)

Let's connect offline and I can share details. I also have some ideas on how to improve all of this, but I'm not yet sure which way to go.