Page 2 of 2

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

Posted: Thu Sep 14, 2023 10:32 am
by 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)

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

Posted: Sun Sep 17, 2023 7:16 pm
by arne_v
jreagan wrote:
Sun Sep 17, 2023 6:13 pm
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


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

Posted: Mon Sep 18, 2023 1:32 am
by joukj
If I add /name=(as_is,short) to the the CXX-command I get the same error in this example....

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

Posted: Mon Sep 18, 2023 3:34 am
by 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

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

Posted: Mon Sep 18, 2023 1:56 pm
by 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.

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

Posted: Mon Sep 18, 2023 3:19 pm
by 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?

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

Posted: Mon Sep 18, 2023 4:21 pm
by hb
arne_v wrote:
Mon Sep 18, 2023 3:20 pm
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.

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

Posted: Mon Oct 23, 2023 4:46 am
by joukj
After the V9.2-1 Update V2.0 I cannot reproduce this error.
So it is solved.