Discussion:
cross tools and CLD scope
(too old to reply)
Craig A. Berry
2021-10-17 23:49:29 UTC
Permalink
So I finally got around to bringing up a v9.1-A system and took a swing
at trying to build something with the cross tools on Itanium. The docs
for those tools mention SYS$MANAGER:X86_XTOOLS$SYLOGIN.COM, which, among
other things, "Adds the cross-tools specific command definitions to the
CLI table of a process."

So far so good. You wouldn't want to mangle your system command tables
on your Itanium system if you were still trying to target Itanium some
of the time. But, as far as I can see, CLD definitions -- unlike logical
names and symbols -- are not inherited by subprocesses. Is that really
true?

Here is my conundrum:

$ show symbol cc
CC == "XCC"
$ cc/vers
VSI C X7.4-528 (GEM 50V6F) for X86 on OpenVMS IA64 V8.4-2L3
$ xcc/vers
VSI C X7.4-528 (GEM 50V6F) for X86 on OpenVMS IA64 V8.4-2L3
$ mmk
CC/DECC/NOANSI_ALIAS
/Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/NoList/float=ieee/ieee=denorm/NAMES=(SHORTENED)/Define=(PERL_CORE,_USE_STD_STAT=1)
PERLMINI.C
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\XCC\
%MMK-F-ERRUPD, error status %X00038090 occurred when updating target
PERLMINI.OBJ

Clearly the symbol definition does what's on the tin and runs the XCC
command when CC is invoked, and clearly the process I'm starting from
knows what the XCC command is. But when MMK creates a subprocess to run
a command, that process has no idea what XCC means.

Surely I am not the first person to encounter this. Any real-world
build system using MMS or MMK would encounter the same thing. Do I
really have to hack up the command definitions to stuff the cross tools
commands into the system table, and then figure out how to unstuff them
later when I want to target Itanium rather than x86_64?
Simon Clubley
2021-10-18 00:03:44 UTC
Permalink
Post by Craig A. Berry
Surely I am not the first person to encounter this. Any real-world
build system using MMS or MMK would encounter the same thing. Do I
really have to hack up the command definitions to stuff the cross tools
commands into the system table, and then figure out how to unstuff them
later when I want to target Itanium rather than x86_64?
Can you create a custom DCLTABLES for your account (call it CRAIGDCL
or something similar), and have that as your login DCL command table
using AUTHORIZE ?

Look at SET COMMAND/REPLACE and SET COMMAND/OUTPUT for ideas.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
David Jones
2021-10-18 14:28:47 UTC
Permalink
Post by Simon Clubley
Can you create a custom DCLTABLES for your account (call it CRAIGDCL
or something similar), and have that as your login DCL command table
using AUTHORIZE ?
If you want to switch back and forth between native build and cross build,
that doesn't solve anything. x86_tools$sylogin.com does more to your
environment than just modify the command tables (i.e. sets logicals and
DCL symbols).

I had the problem that my build creates an executable that needs to be
run as part of the build. The MMS file had to recognize when I was in the
cross build environment, then selectively undo the changes to the CC and
LINK commands in order to get a native build of just that image.
Arne Vajhøj
2021-10-18 00:04:19 UTC
Permalink
Post by Craig A. Berry
So I finally got around to bringing up a v9.1-A system and took a swing
at trying to build something with the cross tools on Itanium.  The docs
for those tools mention SYS$MANAGER:X86_XTOOLS$SYLOGIN.COM, which, among
other things, "Adds the cross-tools specific command definitions to the
CLI table of a process."
So far so good.  You wouldn't want to mangle your system command tables
on your Itanium system if you were still trying to target Itanium some
of the time. But, as far as I can see, CLD definitions -- unlike logical
names and symbols -- are not inherited by subprocesses.  Is that really
true?
$ show symbol cc
  CC == "XCC"
$ cc/vers
VSI C X7.4-528 (GEM 50V6F) for X86 on OpenVMS IA64 V8.4-2L3
$ xcc/vers
VSI C X7.4-528 (GEM 50V6F) for X86 on OpenVMS IA64 V8.4-2L3
$ mmk
CC/DECC/NOANSI_ALIAS
/Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/NoList/float=ieee/ieee=denorm/NAMES=(SHORTENED)/Define=(PERL_CORE,_USE_STD_STAT=1)
PERLMINI.C
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
 \XCC\
%MMK-F-ERRUPD, error status %X00038090 occurred when updating target
PERLMINI.OBJ
Clearly the symbol definition does what's on the tin and runs the XCC
command when CC is invoked, and clearly the process I'm starting from
knows what the XCC command is.  But when MMK creates a subprocess to run
a command, that process has no idea what XCC means.
Surely I am not the first person to encounter this.  Any real-world
build system using MMS or MMK would encounter the same thing.  Do I
really have to hack up the command definitions to stuff the cross tools
commands into the system table, and then figure out how to unstuff them
later when I want to target Itanium rather than x86_64?
Two ideas:
* maybe MMK can be convinced to @ that COM file as the first thing in
the subprocess
* create a X64DCLTABLES and create an account X64CRAIG with that
as default CLITABLES

Arne
Bob Wilson
2021-10-18 00:56:13 UTC
Permalink
I don't know if this will solve your problem (I'm not familiar with MMK), but for MMS we use the .FIRST directive to run a command procedure which, among other things, runs a setup command procedure for "tools" (worked fine in the IA64 port, haven't tried it yet for x86)
Robert A. Brooks
2021-10-18 02:06:07 UTC
Permalink
Post by Bob Wilson
I don't know if this will solve your problem (I'm not familiar with MMK), but
for MMS we use the .FIRST directive to run a command procedure which, among
other things, runs a setup command procedure for "tools" (worked fine in the
IA64 port, haven't tried it yet for x86)
Using the .FIRST directive in MMS works with the IA64-based X86 cross-tools
compilers.
--
-- Rob
hb
2021-10-18 09:41:42 UTC
Permalink
Post by Robert A. Brooks
Post by Bob Wilson
I don't know if this will solve your problem (I'm not familiar with MMK), but
for MMS we use the .FIRST directive to run a command procedure which, among
other things, runs a setup command procedure for "tools" (worked fine in the
IA64 port, haven't tried it yet for x86)
Using the .FIRST directive in MMS works with the IA64-based X86
cross-tools compilers.
Yes, command tables are not propagated to spawned subprocesses. This
affects MMS/MMK.

As mentioned, there is a .FIRST for MMS/MMK, you should have the cross
tools setup in the .FIRST. If you don't want to change the existing
makefile, ahem description file, you can concatenate a "first" file with
your existing one: /DESCRIPTION=("DESCRIP+FIRST"). Yes, quoted. This
works for MMS. I can't get that to work for MMK. Here you may need
something like "$ pipe type/noheader descrip.mms+first.mms |
mmk/descr=sys$pipe". For MMS there can be only one first in the
concatenated description. That explains my order of the plus list. The
last one wins. For MMK you can have several, all seem to be executed. If
you use MMS and already have a .FIRST in your DESCRIP.MMS, you may need
to copy the actions from that to the "first" description file.
Simon Clubley
2021-10-18 17:38:25 UTC
Permalink
That's all impressive and scary. Luckily editing .FIRST or the code
that generates it to include the cross tools set-up got me as far as I
can get with that mechanism. Then I was on to cases where code is
generated that needs to be compiled and run natively to probe for
features that will then be used to generate additional code that will
need to be built with the cross tools. It's not going to be pretty.
[...] stuff removed
That seems more complicated than it needs to be
You can remove the cross-build changes this way . . .
@sys$startup:X86_XTOOLS$SYLOGIN.COM "" "" "TRUE"
I also build a few layered products whose bootstrap tools need to run
on the build system, so I'm constantly flipping between native and
cross builds in the context of a build.
Disclaimer: I am more familiar with the gcc approach to building
and using embedded toolchains than I am with the LLVM approach
to building them.

However, I am aware that clang uses target triples to select the
target. Do the VSI cross-compiler toolchains also use target triples
underneath the DCL commands ?

If so, is there any possibility of just invoking the tools directly,
bypassing the DCL commands, and specify the target triple for x86-64
VMS on the command line directly ?

If you could do that, then it may be one way to run both the native
compilers and cross-compilers in one session without having to switch
between them. I've found the following clang documentation for selecting
the target triple:

https://clang.llvm.org/docs/CrossCompilation.html

in case anyone wants to read up about target triples.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Bob Wilson
2021-10-18 17:53:48 UTC
Permalink
re: @sys$startup:X86_XTOOLS$SYLOGIN.COM "" "" "TRUE"

I think that this only DEASSIGNs the logical names (i.e. the CLD changes are still in effect [which may be incompatible with the native/locally-installed stuff]... you may need to do something like SET COMMAND /TABLE=SYS$LIBRARY:DCLTABLES.EXE to get the default command definitions back)
Craig A. Berry
2021-10-18 19:12:00 UTC
Permalink
Post by Simon Clubley
That's all impressive and scary. Luckily editing .FIRST or the code
that generates it to include the cross tools set-up got me as far as I
can get with that mechanism. Then I was on to cases where code is
generated that needs to be compiled and run natively to probe for
features that will then be used to generate additional code that will
need to be built with the cross tools. It's not going to be pretty.
[...] stuff removed
That seems more complicated than it needs to be
You can remove the cross-build changes this way . . .
@sys$startup:X86_XTOOLS$SYLOGIN.COM "" "" "TRUE"
I also build a few layered products whose bootstrap tools need to run
on the build system, so I'm constantly flipping between native and
cross builds in the context of a build.
Disclaimer: I am more familiar with the gcc approach to building
and using embedded toolchains than I am with the LLVM approach
to building them.
However, I am aware that clang uses target triples to select the
target. Do the VSI cross-compiler toolchains also use target triples
underneath the DCL commands ?
If so, is there any possibility of just invoking the tools directly,
bypassing the DCL commands, and specify the target triple for x86-64
VMS on the command line directly ?
The target triples seem very specific to clang and related front ends.
Given that the front ends for all the cross compilers are ports of the
existing VMS front ends and all of them have been made to believe there
is something resembling GEM under the hood even though it's a
GEM-to-LLVM compatibility layer, what you're suggesting sounds highly
improbable.
David Jones
2021-10-18 20:09:31 UTC
Permalink
That seems more complicated than it needs to be
You can remove the cross-build changes this way . . .
@sys$startup:X86_XTOOLS$SYLOGIN.COM "" "" "TRUE"
That doesn't seem to undo the "CC :== XCC" DCL symbol assignment,
at least on revision X44.24-XG1E.

Loading...