CXX on Alpha, Multiple file versions in [.cxx_repository]: Useful?

[sms]

Code: Select all

   Let's imagine that I have built some open-source C++ program on
various VMS system types, and intended to distribute objects as well as
executables, in case the victim might wish to re-link an executable.

   I know approximately nothing about C++, but my keen observational
skills suggest that the compiler creates a [.cxx_repository] directory. 
On IA64, this directory is populated with a single CXX$DEMANGLER_DB.;1,
and on Alpha, with a bunch of individual <MANGLED_NAME>.obj;* files.

   Questions:

   1. Would the repository file(s) be of any use to a potential victim
(who might wish to re-link an executable)?

   2. Assuming that they're potentially useful:

      On Alpha, it seems that there might be multiple versions of any
   random <MANGLED_NAME>.obj file.  In that case, are they _all_ useful,
   or could the repository be purged with no loss of usefulness?

   If this is documented someplace, a pointer to the useful doc should
suffice, but an actual answer would be at least as appreciated.

[martinv]

For #1, see https://docs.vmssoftware.com/vsi-cxx-us ... _REPOS_SEC
especially under 5.3.1

When the program is linked, the linker searches the repositories for needed template instantiations.

For #2, I'd guess the most recent version of the object file would be sufficient.

But I would see another problem: on Alpha and Integrity, a relink would requite CXXLINK which is does not come wiith OpenVMS,, but is installed with the compiler.

HTH,
Martin

[sms]

Code: Select all

> [...] I'd guess [...]

   I can guess, too, but I was hoping for more than a guess.

   I might guess that the different versions differ by only a timestamp,
but it's still only a guess, and that still wouldn't ensure that only
one version is needed.  (Or which one.  Although I might guess that,
too,)

> [...] on Alpha and Integrity, a relink would requite CXXLINK [...]

   Half right?

> ... and yes, you do not need CXXLINK on IA64.

      https://forum.vmssoftware.com/viewtopic.php?f=12&t=8805&p=19378#p19378

And I've run that experiment, so I can attest to that claim.


   Apropos of not much, all this talk of guesses reminds me of a
conversation between Samuel Spade and a district attorney, an assistant
district attorney, and a stenographer.

[hb]

Let's imagine that I have built some open-source C++ program on
various VMS system types, and intended to distribute objects as well as
executables, in case the victim might wish to re-link an executable.

I know approximately nothing about C++, but my keen observational
skills suggest that the compiler creates a [.cxx_repository] directory.
On IA64, this directory is populated with a single CXX$DEMANGLER_DB.;1,
and on Alpha, with a bunch of individual <MANGLED_NAME>.obj;* files.

Questions:

1. Would the repository file(s) be of any use to a potential victim
(who might wish to re-link an executable)?

2. Assuming that they're potentially useful:

On Alpha, it seems that there might be multiple versions of any
random <MANGLED_NAME>.obj file. In that case, are they _all_ useful,
or could the repository be purged with no loss of usefulness?

If this is documented someplace, a pointer to the useful doc should
suffice, but an actual answer would be at least as appreciated.

On Alpha, there are template instantiation objects in the repository directory. On Alpha, to [re-]link an application that uses templates, these objects must be available. The latest version of any such object file is sufficient.

On Alpha, to [re-]link an application, that uses templates, the CXXLINK tool must be used. (This is the tool which locates the instantiation objects and includes them in a subsequent LINK command).

On x86 and IA64 template instantiations are not in separate objects, so there are no such instantiation objects in the repository directory. On x86 and IA64 CXXLINK is not needed at all.

On x86, IA64 and Alpha the demangler database is in the repository. It is created/written by the C++ and C compilers. The latter uses it for long names with /NAME=SHORTENED. It's purpose is to demangle C++ and shortened C symbols. The tool to do the demangling for both types of symbols is CXXDEMANGLE. The database is not used by the linker.

On (x86 and) IA64 the linker can demangle C++ names for the map file and linker messages. It uses a demangling routine provided by the C++ RTL. It uses demangling information from the object. For x86, the demangling information is not yet included in the objects.

That is, for Alpha and using templates you need to provide the instantiation objects from the repository directory. For Alpha a "potential victim" needs CXXLINK to [re-]link, which to my knowledge is only provided with C++.

[martinv]

> [...] on Alpha and Integrity, a relink would requite CXXLINK [...]

Half right?

> ... and yes, you do not need CXXLINK on IA64.

viewtopic.php?f=12&t=8805&p=19378#p19378

And I've run that experiment, so I can attest to that claim.

Right. I didn't read enough of the documentation:

On I64 systems, the only benefit of using CXXLINK instead of the Linker is that CXXLINK reports non-mangled names of undefined and multiply-defined symbols. It does this by intercepting Linker diagnostics and converting mangled names reported by the Linker to their original names, using the information in the demangler database.

Sorry.

[hb]

Right. I didn't read enough of the documentation:

On I64 systems, the only benefit of using CXXLINK instead of the Linker is that CXXLINK reports non-mangled names of undefined and multiply-defined symbols. It does this by intercepting Linker diagnostics and converting mangled names reported by the Linker to their original names, using the information in the demangler database.

True, it intercepts the UDFSYM and USEUNDEF diagnostics. That is, you will not see the "real" undefined symbols. The linker prints these in the mangled form and adds a secondary message "source code name:" to the USEUNDEF message. So you will see the non-mangled names, even if you do not have access to the demangler database.