raise Exception('Unknown implicit section %s !'%secname)

[KurapicaBS]

C:\Python39>python "G:\CuAssembler\bin\cuasm.py" --bin2asm "G:\elf3.dat" ,023 - - Running CubinFile.loadCubin... ,023 - ENTRY - Loading cubin file G:\elf3.dat... ,044 - - Running CubinFile.disassembleCubin... ,044 - PROC - Disassembling G:\elf3.dat... ,779 - - Func CubinFile.disassembleCubin completed! Time= 12.7356 secs. ,044 - - Func CubinFile.loadCubin completed! Time= 13.0207 secs. ,044 - - Running CubinFile.saveAsCuAsm... ,044 - ENTRY - Saving to cuasm file G:\elf3.cuasm... Traceback (most recent call last): File "G:\CuAssembler\bin\cuasm.py", line 153, in doProcess(infile, outfile, direction) File "G:\CuAssembler\bin\cuasm.py", line 92, in doProcess cubin2cuasm(src, dst) File "G:\CuAssembler\bin\cuasm.py", line 68, in cubin2cuasm cf.saveAsCuAsm(asmname) File "G:\CuAssembler\CuAsm\CuAsmLogger.py", line 210, in wrapper ret = func(*args, **kwargs) File "G:\CuAssembler\CuAsm\CubinFile.py", line 526, in saveAsCuAsm self.writeImplicitSectionAsm(fout, secname) File "G:\CuAssembler\CuAsm\CubinFile.py", line 445, in writeImplicitSectionAsm raise Exception('Unknown implicit section %s !'%secname) Exception: Unknown implicit section .nv.info._ZNK45_GLOBALN22_octane_kernels_cpp1_ii_kernel011Wavelengths33convertFilterSpectrumToLinearSrgbE6float4$1021 !

[cloudcores]

That seems wierd.

Usually the section .nv.info._ZNK45_GLOBAL__N__22_octane_kernels_cpp1_ii_kernel011Wavelengths33convertFilterSpectrumToLinearSrgbE6float4$1021 should contain configurations for kernel _ZNK45_GLOBAL__N__22_octane_kernels_cpp1_ii_kernel011Wavelengths33convertFilterSpectrumToLinearSrgbE6float4$1021, which is the mangled name of kernel functions. However, the trailing $1021 is invalid to be part of kernel function name, thus not likely to be part of this section name.

The exception raised due to the section is declared in the header, but no contents are found in the output of nvdisasm (which is called implicit section in CuAsm). Usually only .symtab/.strtab/.shstrtab or relocation sections can be implicit sections, .nv.info.* contains important configs for kernels and cannot be implicit.

Not quite sure what happened to this cubin... Can you attach the original cubin? If it's propriotary, you can just post the section name parts by cuobjdump -elf G:\elf3.dat.

[KurapicaBS]

The file is produced by linking 2 ELF files and 1 PTX file

3 calls to "cuLinkAddData" for files, elf1.dat, elf2.dat, PTX.c

and finally produces this "elf3.dat" file which causes the problem.

[cloudcores]

Seems the final cubin is generated by linking some intermediate cubins with relocatable device code. For this class of ELF, the section info(and also symbols) is much less regular than standalone cuda c/ptx source file, and is rather difficult to be supported by current CuAssembler.

Sorry for the inconvenience, but hacking cubins with such complex section layouts is far from trivial...

If you have source code for your interested kernel, you can put it in another standalone ptx and hack the result cubin. Providing that kernel does not have too much dependencies, this simpler procedure may be more likely to succeed.

If no hacking is needed, you can format the assembly with control codes via dsass, which only depends on the assembly in nvdisasm output.

[KurapicaBS]

Thanks for taking the time, I appreciate your help.