Customizing NV_MODULE_ID

I was integrating nvcc into a distributed build system and had some trouble with --device-c and --device-link (as needed for NCCL). nvcc --device-link generates an object file that supplies symbols for linking --device-c objects using the host linker. These symbols include NV_MODULE_ID which is generated as tmpxft{pid}00000000_6{src}1_ii_{hash} where pid is the nvcc process ID. This makes the device-link.o generated against one set of device-c.o unusable with another set since the names of their symbols don’t match up. This is easy to accommodate in timestamp-based build systems, but it is difficult in source-hash-based systems since the output depends not only on the source but also on the PID.

I have found that I can work around this issue by fixing nvcc PID, either with unshare -Ufp, or by LD_PRELOAD’ing getpid() that returns a constant value. However, I would prefer if nvcc module ID was deterministic by default, or if I was able to tell nvcc not to use PID in the MODULE_ID, or provide my own MODULE_ID.

file a bug (RFE) at developer.nvidia.com

The instructions are linked to a sticky post at the top of the CUDA programming forum

Thank you! I have opened https://developer.nvidia.com/nvidia_bug/2659879 and will post here about the outcome.

How do I get access to https://developer.nvidia.com/nvidia_bug/2659879?
It says “You are not authorized to access this page.”

You won’t be able to get access to that bug. Bugs filed that way are not publicly accessible.

The bug in question is being worked by NVIDIA and I expect there will be some evidence of this in the next major CUDA release. I can’t provide any more details nor can I give an timeline estimate of when the next major CUDA release will be available.

So secretive! well thanks for the quick reply. I’ll follow the strategies recommended by orivej in the meantime. The flags taken by cudafe++ are also hidden from --help so the best we could do was hex edit cudafe directly.