build: one definition of the arch-sensitive shim flags, and a multi-arch shim image - #153
Merged
Merged
Conversation
…rch shim The same compile command existed in four copies -- shim/Makefile's CXXFLAGS, its nvidia-portable target, and twice inline in ci.yml -- each spelling out -mtls-dialect and targets/x86_64-linux for itself. Adding aarch64 inline would have made six. Divergence between copies is invisible until a shim is built with the wrong TLS dialect and fails to dlopen, which is precisely what #121 was. TLS_DIALECT and CUDA_TARGET are now derived once from uname in shim/Makefile and used everywhere. A third architecture is two lines in one ifeq rather than four edits that can disagree. CI stops inlining the portable build and calls the Makefile target, with CONTAINER=docker because the runtime is the only thing that genuinely differs there; it also stops passing CUDA_INC, which is what let the job and the Makefile disagree about the target directory. elfgate.sh now reports the GLIBC_ABI_GNU2_TLS marker as n/a on non-x86-64 rather than "absent". That string is never emitted on aarch64, so reporting absence there would be a check that cannot fail dressed as a check that passed -- about the very property the gate exists to protect. The numeric glibc floor carries the weight on ARM and is genuinely arch-neutral. With the probes ported (#152) the shim image builds and publishes on both architectures, and both images get real manifest lists. The CUPTI integration is still unexercised on ARM for want of an arm64 GPU node, and the README says so rather than implying full support. Claude-Session: https://claude.ai/code/session_01P5889hA6CrX8ysnQkvv6im
Both arches failed the gate, which is the useful shape of failure: it says the break is mine rather than the architecture's. Calling make -C shim nvidia-portable instead of inlining the compile moved the artifact. The Makefile writes it next to the sources in shim/; the inline copy wrote it to the repo root, and the "Prove it loads" step still looked there -- so dlopen reported a missing file rather than an unloadable one. Running the make target locally did not catch it because the step that consumes the artifact is the next one along. Also fixes a collision the gate never reached: matrixing the job left both arches uploading an artifact under one name, which upload-artifact@v4 refuses. Per-arch now. Claude-Session: https://claude.ai/code/session_01P5889hA6CrX8ysnQkvv6im
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
With the USDT probes ported (#152), the shim image can go multi-arch. Doing that naively would have meant adding
aarch64branches to two more places — so this consolidates first.Four copies became one
The same compile command existed in four places, each spelling out
-mtls-dialectandtargets/x86_64-linuxfor itself:shim/MakefileCXXFLAGS-mtls-dialect=gnushim/MakefileCUDA_INC/CUDA_LIBtargets/x86_64-linuxshim/Makefilenvidia-portableci.yml× 2TLS_DIALECTandCUDA_TARGETare now derived once fromunameand used everywhere. A third architecture is two lines in oneifeqrather than four edits that can silently disagree — and disagreement here is invisible until a shim is built with the wrong TLS dialect and fails todlopen, which is exactly what #121 was.CI stops inlining the portable build and calls
make -C shim nvidia-portablewithCONTAINER=docker(the runtime is the only thing that genuinely differs there). It also stops passingCUDA_INC, which is what let the job and the Makefile disagree about the target directory in the first place.A check that could not fail
elfgate.shgreps forGLIBC_ABI_GNU2_TLS. That is an x86-64 marker — on aarch64 the string is never emitted, so the gate would have reportedabsentand meant nothing by it. A check that cannot fail, dressed as a check that passed, about the very property the gate exists to protect.It now reports
n/a (x86-64 marker; this object is AArch64). The numeric glibc floor carries the weight on ARM, and that check is genuinely arch-neutral: a TLS dialect that raised the requirement would show up in it.The flip
Dockerfile.shimwas already arch-parameterised (#151), so removing theif: matrix.arch == 'amd64'guards is all that remained. Both images now build on both arches in CI and publish real manifest lists.Verified locally
The exact path CI now takes —
make -C shim nvidia-portable— producesGLIBC_ABI_GNU2_TLS absent,glibc requires 2.34 (limit 2.34), one export, no libstdc++, no runpath, 14 USDT notes,-> portable. Shim suite exits 0; 36 packages pass.Still not tested on ARM
The CUPTI integration, for want of an arm64 GPU node. That part is arch-independent C++ calling CUPTI APIs rather than anything register-level, but it has not been run, and the README says so rather than implying full support.
https://claude.ai/code/session_01P5889hA6CrX8ysnQkvv6im