Operating System - OpenVMS
1748201 Members
3137 Online
108759 Solutions
New Discussion юеВ

Re: Problem with Linker Options file on Alpha

 
SOLVED
Go to solution
Hoff
Honored Contributor

Re: Problem with Linker Options file on Alpha

>I've been on VMS for 30 years and seen big improvements in speed but this would still be far slower than accessing the data directly.

Don't solve yesterday's problem. This application is in maintenance, so it's not something I'd expect to see much time spent with updates; in these cases, simple and functional and a little slower always wins out over clever and fast and more difficult to support.
John Gillings
Honored Contributor

Re: Problem with Linker Options file on Alpha

John,

> Better yet, SYS$TRNLNM should accept wildcards

True, it's been asked for many times. It won't ever happen :-(

> still be far slower than accessing the data directly

Also true, but unless you're doing this thousands of times a day do you really care if it takes 0.1 second or 0.01 second?

Attached is a first cut DCL procedure which will deassign wildcard logical names. I've done some minimal testing. I think it covers all tables and modes.

$ @DEASSIGN_WILD *YOURSTRING*

or

$ @DEASSIGN_WILD *YOURSTRING* /TABLE=SOME_TABLE

The debugging part expects a program called "ECHO" in SYS$LOGIN
A crucible of informative mistakes
John Gillings
Honored Contributor

Re: Problem with Linker Options file on Alpha

attached is ECHO.MAR

Pity VMS doesn't have an ECHO command. It's very useful for debugging...

(and note it does something quite different from WRITE SYS$OUTPUT).

$ MACRO ECHO
$ LINK ECHO
$ echo="$SYS$LOGIN:ECHO"
A crucible of informative mistakes
John McL
Trusted Contributor

Re: Problem with Linker Options file on Alpha

Thanks John. I'd dismissed the idea of piping because the parsing of the output wasn't going to be simple but what you've given me is an elegant and self-contained solution.

It also wouldn't be difficult to create a similar command procedure that just counted the logical names that match a certain wildcard pattern, and that's something we might find useful in our software.

I'll fire this up today and see how it goes.
John McL
Trusted Contributor

Re: Problem with Linker Options file on Alpha

I've just been reminded that we've had a problem with logical names being created with non-printable characters. These didn't get noticed during testing and the code hit the production systems in this form. (Sorry, I should have mentioned this problem in my initial post.)

These can only be removed by either a SYS$DELLNM with a name that's manually matched to the hex values found by examining the process's tables or by rebooting the machine, and if these are clusterwide logicals the problem is even greater.

Sure the problem was a programmer error when using $CRELNM, but catching the problem relies on testers who will examine each logical name. Checking the output of $SHOW LOGICALS might not reveal this problem unless weird characters appear in names and the tester notices them.

(I suppose $CRELLNM could reject names with non-printing chars except by a flag reserved to HP, but would DCL symbol substitution been an alternative.)

This puts us back to the "never happen" change to $TRNLNM or the more likely wildcard deassign once I resolve the problem with processing order when linking.
John McL
Trusted Contributor

Re: Problem with Linker Options file on Alpha

Here's something odd ... Halmut mentioned it and I've just seen it for myself.

When linking with SYS$BASE_IMAGE/SHARE in the options file it appears first in the .MAP file, where the modules are listed, i.e. ...
Module name
-----------
SYS$BASE_IMAGE
(my function)
DECC$SHR_EV56
LIBRTL
LIBOTS
SYS$PUBLIC_VECTORS
...but at the end of the .MAP file the Link command is displayed and shows my function prior to SYS$BASE_IMAGE.EXE. Is SYS$BASE_IMAGE being processed by the Linker before my code?

I seem to have two alternatives, a Linker option file entry or the call to LIB$FIND_IMAGE_SYMBOL. The first has multiply defined symbols (or an undefined symbol) and the latter has the ILLSYMLEN problem when accessing SYS$BASE_IMAGE.EXE.

John Gillings
Honored Contributor

Re: Problem with Linker Options file on Alpha

John,

Apologies! I didn't realise my LIB$FIS example code was executing on Itanium. I've just tried it on Alpha and I get a very ugly stackdump with non-printable characters. So scratch that plan!

Yet another (even uglier?) possibility, build youself a little shareable image in MACRO32 (or any other language that isn't C) linked against the base image, which exports a routine which returns the address of LNM$AL_HASHTBL.

That isolates the reference to the base image so the additional symbols don't clash with DECC$SHR.

LMN_AL_HASHTBL.MAR
.TITLE LNM_AL_HASHTBL
.EXTERNAL LNM$AL_HASHTBL
.ENTRY LNM_AL_HASHTBL,^M<>
MOVAL LNM$AL_HASHTBL,R0
RET
.END

$ MACRO LMN_AL_HASHTBL
$ LINK/SHARE LMN_AL_HASHTBL+SYS$INPUT/OPTIONS
GSMATCH=LEQUAL,100,100
SYS$LOADABLE_IMAGES:SYS$BASE_IMAGES/SHARE
SYMBOL_VECTOR=(LMN_AL_HASHTBL=PROCEDURE)
$
$ LINK yourimage+SYS$INPUT/OPTIONS
LNM_AL_HASHTBL/SHARE


It ain't pretty, but it will work, and should be the same on both Alpha and Itanium.

An example of an application of Hext's Law: - "Adding a further level of indirection solves all problems" :-)
A crucible of informative mistakes
John McL
Trusted Contributor

Re: Problem with Linker Options file on Alpha

John G, I took your idea and modified it. I created a C function whose only task is to return the address of LNM$AL_HASHTBL and I put the name of this file into a named linker cluster in a Linker options file so that it is processed before SYS$BASE_IMAGE.EXE/SHARE/SELECTIVE, which in turn is processed before my main code.

It all probably would have worked fine if our automated functions didn't also put the name of my new file in the Linker options, which meant it was linked twice. That would be bearable for a one-off build but we rebuild this code every day and we use LIB$FIND_IMAGE_SYMBOL to access it, and L$FIS dumps a traceback every time because of compilation warnings.

I'm about to wrestle with our automated procedures to see what can be done.
John McL
Trusted Contributor

Re: Problem with Linker Options file on Alpha

Question: Changing our automated procedures is not my first choice because it will involve a lot of testing.

Can I create a shareable image library from SYS$BASE_IMAGE.EXE and more importantly will the library contain the symbol LNM$AL_HASHTBL? If I can link against a shareable image library I won't need to use a cluster specification to get the Linker processing in the correct order because the shareable image libraries are accessed last.

I've created sucha library by I'm worried because a LIB/LIST/NAMES doesn't list my symbol and when I try to link the linker is looking for SYS$COMMON:[SYSLIB]SYS$BASE_IMAGE.EXE (not SYS$LOADABLE_IMAGES). I vaguely recall a logical being required to point to the correct directory but was it /exec/system?
H.Becker
Honored Contributor

Re: Problem with Linker Options file on Alpha

(OK, I give up on my first name. Again, I apologize for the layout.)

>>> 1 - The Linker manual says that the equivalent to /SYSEXE when using a Linker options file is
ALPHA$LOADABLE_IMAGES:SYS$BASE_IMAGE.EXE/SHARE and doesn't mention /SELECTIVE.

Please have a look at the 8.3 linker manual

2.4 Resolving Symbols Defined in the OpenVMS Executive
For I64 linking, you link against the OpenVMS executive by specifying the
/SYSEXE qualifier. When this qualifier is specified, the linker selectively
^^^^^^^^^^^
processes the system shareable image, SYS$BASE_IMAGE.EXE, located in the
directory pointed to by the logical name IA64$LOADABLE_IMAGES. The linker
does not process SYS$BASE_IMAGE.EXE by default. Note that, because the
linker is processing a shareable image, references to symbols in the OpenVMS
executive are fixed up at image activation.

OK, the Alpha and VAX part of the manual wasn't updated, but it still has

6.4 Resolving Symbols Defined in the OpenVMS Executive
...
For Alpha linking, you link against the OpenVMS executive by specifying
the /SYSEXE qualifier. When this qualifier is specified, the linker selectively
^^^^^^^^^^^
processes the system shareable image, SYS$BASE_IMAGE.EXE, located in the
directory pointed to by the logical name ALPHA$LOADABLE_IMAGES. The
linker does not process SYS$BASE_IMAGE.EXE by default.

>>> 2 - Sure linking order seems to be important but if I say $ LINK A, B.OPT/OPT mean that A.OBJ gets processed first and then the
contents of linker options file B.OPT? This would mean that there should be no problem. (It is possible that the automated
procedures that we use here are merging a number of options files and might be re-ordering things - I'll investigate.)

Please have a look at the 8.3 linker manual, starting with paragraph 2.3

2.3 Ensuring Correct Symbol Resolution
For many link operations, the order in which the input files are specified in
the LINK command is not important. However, in complex link operations that
specify multiple library files or process input files selectively, correct symbol
resolution may become problematic.

>>> 3 - When you discuss using LIB$FIND_IMAGE_SYMBOL and again near the end of your response you talk about 'LNM$AL_HASHTBL' being
Double Valued Global Symbol/Version Mask". What do you mean by this? I understand the last part - which just means global address -
but are you saying that there's two addresses of the same name (presumably one in my initial address space and another because of
the activation of SYS$BASE_IMAGE.EXE?

Use analyze/image and find the symbol. Get a pre-8.3 manual, all the bits shown by analyze are described in appendix B.

>>> Module name
-----------
SYS$BASE_IMAGE
(my function)
DECC$SHR_EV56
LIBRTL
LIBOTS
SYS$PUBLIC_VECTORS
...but at the end of the .MAP file the Link command is displayed and shows my function prior to SYS$BASE_IMAGE.EXE. Is
SYS$BASE_IMAGE being processed by the Linker before my code?

Yes, an effect of /SHARE. Again, check the 8.3 manual and read 2.3.1 Understanding Cluster Creation.
The linker groups input files into clusters and processed the clusters. Without a CLUSTER= your function ends in the
DEFAULT_CLUSTER which comes after any named cluster. SYS$BASE_IMAGE/SHARE makes SYS$BASE_IMAGE a named cluster. So it is processed
before the DEFAULT_CLUSTER. DECC$SHR_EV56 and friends come from imagelib which is processed after the DEFAULT_CLUSTER. That's all
explained in the manual. And that's why I had a CLUSTER= in my example. That changes the order of input file processing!

>>> Apologies! I didn't realise my LIB$FIS example code was executing on Itanium. I've just tried it on Alpha and I get a very ugly
stackdump with non-printable characters. So scratch that plan!

Yes, scratch it, for several reasons. On the difference, there are no more double valued symbols on I64, that is in ELF.

>>> Yet another (even uglier?) possibility, build youself a little shareable image in MACRO32 (or any other language that isn't C)
linked against the base image, which exports a routine which returns the address of LNM$AL_HASHTBL.

Why? You just can figure out the right linker options file and it will work. The basics were already shown in my example.

>>> John G, I took your idea and modified it. I created a C function whose only task is to return the address of LNM$AL_HASHTBL and
put the name of this file into a named linker cluster in a Linker options file so that it is processed before
SYS$BASE_IMAGE.EXE/SHARE/SELECTIVE, which in turn is processed before my main code.

>>> It all probably would have worked fine if our automated functions didn't also put the name of my new file in the Linker options,
which meant it was linked twice. That would be bearable for a one-off build but we rebuild this code every day and we use
LIB$FIND_IMAGE_SYMBOL to access it, and L$FIS dumps a traceback every time because of compilation warnings.

So the problem is that you can't control the linker options file.

>>> Can I create a shareable image library from SYS$BASE_IMAGE.EXE and more importantly will the library contain the symbol
LNM$AL_HASHTBL? If I can link against a shareable image library I won't need to use a cluster specification to get the Linker
processing in the correct order because the shareable image libraries are accessed last.

>>> I've created sucha library by I'm worried because a LIB/LIST/NAMES doesn't list my symbol and when I try to link the linker is
looking for SYS$COMMON:[SYSLIB]SYS$BASE_IMAGE.EXE (not SYS$LOADABLE_IMAGES). I vaguely recall a logical being required to point to
the correct directory but was it /exec/system?

Von hinten durch die Brust ins Auge? The base image is a special shareable image. I would not expect this to work. And if
LNM$AL_HASHTBL is not listed by librarian, then the linker will not find it.

It would be sooo easy to just add "/SYSEXE".