CXX on X86 : corrupt .obj file created without any error messages.

[joukj]

Hi I get the following:

Code: Select all

rumba-jj) cxx/vers
clang version 10.0.1 (git@bitbucket.org:vms_software/llvm-10.0.1.git 1944c289616
bb7073af92c05d3ba6e7fd5d7ed0e)
Build date: 09-01-2023
Target: x86_64-OpenVMS
Thread model: posix
InstalledDir: RUMBA$DKA100:[SYS0.SYSCOMMON.][SYSEXE]
rumba-jj) define diplib []
rumba-jj) define eigen [.eigen]
%DCL-I-SUPERSEDE, previous value of EIGEN has been superseded
rumba-jj) cxx/stan=gnu14 matrix.cpp
rumba-jj) lib/crea l.olb matrix  
%LIBRAR-F-INSERTERR, error inserting _ZN5Eigen15PlainObjectBaseINS_6MatrixINSt3_
_17complexIdEELin1ELin1ELi0ELin1ELin1EEEE10resizeLikeINS_14TriangularViewIKNS_5B
lockIKS5_Lin1ELin1ELb0EEELj2EEEEEvRKNS_9EigenBaseIT_EE in $DSTM:[JOUKJ.test.bugs
.cxx.corrupt_ob
-RMS-E-EOF, end of file detected

I attached the files whith which I created this "reproducer". Sorry that it is not "simple"

(removed attachment)

[arne_v]

You can use /NAMES=SHORTENED to get the old CRC-suffix behavior

Doesn't work for me:

Code: Select all

$ type zz.cxx
void cxx45678901234567890123456789012345678901234567890123456789012345678901234567890()
{
}

$ cxx zz
$ libr/obj/crea namlen
$ libr/obj/ins namlen zz
$ libr/obj/list/name namlen
Directory of ELF OBJECT library DKA0:[arne]namlen.OLB;2 on 17-SEP-2023 19:15:38
Creation date:  17-SEP-2023 19:15:38      Creator:  Librarian I01-47
Revision date:  17-SEP-2023 19:15:38      Library format:   6.0
Number of modules:      1                 Max. key length:  1024
Other entries:          1                 Preallocated index blocks:    213
Recoverable deleted blocks:        0      Total index blocks used:        2
Max. Number history records:      20      Library history records:        1

Module ZZ
_Z80cxx45678901234567890123456789012345678901234567890123456789012345678901234567890v

$ cxx/name=shorten zz
$ libr/obj/crea namlen
$ libr/obj/ins namlen zz
$ libr/obj/list/name namlen
Directory of ELF OBJECT library DKA0:[arne]namlen.OLB;3 on 17-SEP-2023 19:15:39
Creation date:  17-SEP-2023 19:15:39      Creator:  Librarian I01-47
Revision date:  17-SEP-2023 19:15:39      Library format:   6.0
Number of modules:      1                 Max. key length:  1024
Other entries:          1                 Preallocated index blocks:    213
Recoverable deleted blocks:        0      Total index blocks used:        2
Max. Number history records:      20      Library history records:        1

Module ZZ
_Z80cxx45678901234567890123456789012345678901234567890123456789012345678901234567890v

[joukj]

If I add /name=(as_is,short) to the the CXX-command I get the same error in this example....

[jreagan]

Sigh. I'll tell the team

Added in 7 hours 17 minutes 18 seconds:
There was a confusion about what the word "external" means in the definition of /NAMES=SHORTENED. Names inside of an

Code: Select all

extern C

statement vs any name visible to the linker. It is currently the extern C names.

So with longer than 1024 mangled names (which are currently not shortened), allocating a larger key length at OLB creation time should fix it. I might even suggest that we change the default of LIBR OLB from 1024 to 2048 or 4096 might be a good thing with all the C++ names it might encounter

[hb]

The problem originally reported was/is a bug in LIBRARIAN. It can be reproduced with 10 global symbols of an "appropriate" name length - significantly less than 1024. What that is is left as an exercise for the interested reader . Obviously, this wasn't caught when testing the IA64 LIBRARIAN. That's not really a surprise. As far as I know, none of the IA64 compilers created symbols with more than 31 characters. It was tested that single long symbols could be inserted into the global name table. This was done by patching the object files. Obviously this was not a comprehensive test.

The bug will be fixed in a future update.

[arne_v]

So we will get an updated librarian in some VMS update that fixes the real problem.

John will consider whether /NAME=SHORTEN should behave more VMSish and apply to all external symbols not just extern "C" symbols.

If yes, then it will be in a C++ compiler update at some point in time.

If no, then we may get an updated librarian in some VMS update that allows us to define key size > 1024 to allow such C++ code to be inserted.

Added in 28 seconds:
Have I understood it correct?

[hb]

So we will get an updated librarian in some VMS update that fixes the real problem.

Yes.

John will consider whether /NAME=SHORTEN should behave more VMSish and apply to all external symbols not just extern "C" symbols.

That's also my understanding.

If yes, then it will be in a C++ compiler update at some point in time.

Yes.

If no, then we may get an updated librarian in some VMS update that allows us to define key size > 1024 to allow such C++ code to be inserted.

s/If no, then we/We/

FWIW, looking at the string table and selecting all the mangled names, the _ZN*, the longest symbol name I noticed in matrix.obj was 753 characters.

[joukj]

After the V9.2-1 Update V2.0 I cannot reproduce this error.
So it is solved.