Yesterday, I tried what I thought would be a simple challenge: writing "Hello, world!" in x86 assembly in OpenVMS using llvm-mc (X86ASM). But I couldn't figure out the magic assembler directives to create a program that does anything other than immediately crash with an ACCVIO on NULL.

Even after I commented out *all* of my code, leaving only a "ret" statement, it still crashes, so there must be some fundamental error in the .obj file's generated ELF metadata. Here's what I wrote:

# Writes "Hello, World" to the console using only system calls. Runs on OpenVMS x86-64 only.

.global ELF$TFRADR

.section $CODE$, "ax", "progbits" # EXE,SHR
.align 16

.cfi_startproc
ELF$TFRADR:
START:
mov message_descr@GOTPCREL(%rip),%rdi
mov $0x0100,%ax
call LIB$PUT_OUTPUT@PLT
mov $0x00000001,%edi
mov $0x0100,%ax
call SYS$EXIT@PLT
pop %rbp
ret
.cfi_endproc

.section .data
message:
.ascii "Hello, world!"
message_end:
.align 8
message_descr:
.word 1 # must-be-one field
.byte 14 # DSC$K_DTYPE_T
.byte 1 # DSC$K_CLASS_S
.word -1 # must-be-minus-one field
.quad (message_end - message)
.quad message

I tried a number of variations, including a 32-bit descriptor, which also didn't work, and as I said, it crashes even with just a "ret" line. Adding/removing the "@PLT" and "%GOTPCREL(%rip)" didn't change anything, and I never saw a single line of output in my experiments. The Pascal object code for the following program looks almost identical to my asm code except that it constructs the descriptor on the stack:

(* Test minimal Output *)

[inherit('pascal$lib_routines', 'starlet')]

program Hello;
begin
lib$put_output('Hello, world!');
$exit(1)
end.

The only clue that something may be wrong with my asm directives is that ana/obj/disass shows the Pascal .OBJ file's code section as:

..section $CODE$, "ax", "progbits" # EXE,SHR

But my asm version, despite including the same source line, generates a file that disassembles into this:

..section $CODE$, "ax", "progbits" # EXE

The part after the "#" is a comment, so that's even more weird. I tried more UNIX-like section directives like ".text" and again, no difference. BTW, the VMS x86 disassembler treats constants as hex but doesn't include a "0x", so if you copy-and-paste the code into a gas-style .s file, it thinks they're octal numbers and you have to add the prefix. So I'm not surprised that there appears to be some round-trip issue with the disassembled section header directive not giving the same result when reassembled in llvm-mc.

The VMS port of llvm-mc also doesn't recognize "$" as a reference to the current location in the source file. That's why I had to write "(message_end - message)" to get the string size, and not a line like:

message_len = ($ - message)

When I try using "$" like that, I get "error: invalid token in expression" and "error: missing expression". Can someone please tell me what I need to change to generate a working minimal VMS .exe using llvm-mc?

Thanks,
Jake Hamby

On 2023-11-07, Jake Hamby (Solid State Jake) <jake.hamby@gmail.com> wrote:
>
> # Writes "Hello, World" to the console using only system calls. Runs on OpenVMS x86-64 only.
>
> .global ELF$TFRADR
>
> .section $CODE$, "ax", "progbits" # EXE,SHR
> .align 16
>
> .cfi_startproc
> ELF$TFRADR:
> START:
> mov message_descr@GOTPCREL(%rip),%rdi
> mov $0x0100,%ax
> call LIB$PUT_OUTPUT@PLT
> mov $0x00000001,%edi
> mov $0x0100,%ax
> call SYS$EXIT@PLT
> pop %rbp
> ret
> .cfi_endproc
>
> .section .data
> message:
> .ascii "Hello, world!"
> message_end:
> .align 8
> message_descr:
> .word 1 # must-be-one field
> .byte 14 # DSC$K_DTYPE_T
> .byte 1 # DSC$K_CLASS_S
> .word -1 # must-be-minus-one field

Why do you have a word here instead of a longword ?

> .quad (message_end - message)
> .quad message
>

> I tried a number of variations, including a 32-bit descriptor, which also didn't work, and as I said, it crashes even with just a "ret" line. Adding/removing the "@PLT" and "%GOTPCREL(%rip)" didn't change anything, and I never saw a single line of output in my experiments. The Pascal object code for the following program looks almost identical to my asm code except that it constructs the descriptor on the stack:
>
> (* Test minimal Output *)
>
> [inherit('pascal$lib_routines', 'starlet')]
>
> program Hello;
> begin
> lib$put_output('Hello, world!');
> $exit(1)
> end.
>
> The only clue that something may be wrong with my asm directives is that ana/obj/disass shows the Pascal .OBJ file's code section as:
>
> .section $CODE$, "ax", "progbits" # EXE,SHR
>
> But my asm version, despite including the same source line, generates a file that disassembles into this:
>
> .section $CODE$, "ax", "progbits" # EXE
>
> The part after the "#" is a comment, so that's even more weird. I tried more UNIX-like section directives like ".text" and again, no difference. BTW, the VMS x86 disassembler treats constants as hex but doesn't include a "0x", so if you copy-and-paste the code into a gas-style .s file, it thinks they're octal numbers and you have to add the prefix. So I'm not surprised that there appears to be some round-trip issue with the disassembled section header directive not giving the same result when reassembled in llvm-mc.
>

The clues might be elsewhere.

Generate a linker memory map and see if there are any clues in there.

Look to see what the entry point is in both cases and if there's
something that should be getting called before your entry point.

You may need to do something with the linker command.

Try posting your _exact_ linker and assembly commands.

Also try posting your traceback.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On Tuesday, November 7, 2023 at 10:55:01 AM UTC-8, Simon Clubley wrote:
> >
> The clues might be elsewhere.
>
> Generate a linker memory map and see if there are any clues in there.
>
> Look to see what the entry point is in both cases and if there's
> something that should be getting called before your entry point.
>
> You may need to do something with the linker command.
>
> Try posting your _exact_ linker and assembly commands.
>
> Also try posting your traceback.

Good suggestions. My assembler command is "llvmmc -o=vms-hello.obj --filetype=obj vms-hello.s". I'm using no special linker options. Here's what the linker map looks like for the asm version:

+---------------------------+
! Object and Image Synopsis !
+---------------------------+

Module/Image File Ident Attributes Bytes Creation Date Creator
------------ ---- ----- ---------------- ----- ------------- -------
(Unknown) (Unknown) 119 (Unknown) (Unknown)
DISK$X86DATA:[home.jhamby.Projects]vms-hello.obj;5
LIBRTL X01-001 0 30-SEP-2023 07:11 Linker I02-94
SYS$COMMON:[SYSLIB]LIBRTL.EXE;1
SYS$PUBLIC_VECTORS X-3 Sel 0 16-MAY-2023 13:31 Linker I02-94
SYS$COMMON:[SYSLIB]SYS$PUBLIC_VECTORS.EXE;1

Key for Attributes
+------------------------------------------+
! Sel - Module was selectively searched !
+------------------------------------------+

+------------------+
! Cluster Synopsis !
+------------------+

Cluster Match Majorid Minorid
------- ----- ------- ----------
DEFAULT_CLUSTER
LIBRTL LESS/EQUAL 1 1
SYS$PUBLIC_VECTORS EQUAL 14443 2200863325

+------------------------+
! Image Segment Synopsis !
+------------------------+

Seg# Cluster Type Pglts Base Addr Disk VBN PFC Protection Attributes
---- ------- ---- ----- --------- -------- --- ---------- ----------
0 DEFAULT_CLUSTER LOAD 1 00002000 2 0 READ WRITE
1 LOAD 1 Q-00000000
80000000 3 0 READ ONLY EXECUTABLE
2 LOAD 1 Q-00000000
80002000 4 0 READ ONLY FIXED OFFSET,[UNWIND]
3 LOAD 1 Q-00000000
80004000 5 0 READ ONLY FIXED OFFSET
4 LOAD 1 00004000 6 0 READ ONLY EXECUTABLE
5 DYNAMIC 2 Q-00000000
80006000 7 0 READ ONLY

Key for special characters above
+----------------------+
! Q - Quad Value !
+----------------------+

+--------------------------+
! Program Section Synopsis !
+--------------------------+

Psect Name Module/Image Base End Length Align Attributes
---------- ------------ ---- --- ------ ----- ----------
..data 00002000 00002025 00000026 ( 38.) QUAD 3 CON,REL,LCL,NOSHR,NOEXE, WRT,
NOVEC, MOD
vms-hello 00002000 00002025 00000026 ( 38.) QUAD 3
$LINKER SCODE$ 00004000 0000402F 00000030 ( 48.) OCTA 4 CON,REL,GBL,NOSHR, EXE,NOWRT,
NOVEC, MOD
<Linker> 00004000 0000402F 00000030 ( 48.) OCTA 4
$CODE$ Q-00000000 00000000 00000000 OCTA 4 CON,REL,LCL,NOSHR, EXE,NOWRT,
NOVEC, MOD
80000000 80000020 00000021 ( 33.)
vms-hello Q-00000000 00000000 00000000 OCTA 4
80000000 80000020 00000021 ( 33.)
$LINKER C$0 Q-00000000 00000000 00000000 OCTA 4 CON,REL,LCL,NOSHR, EXE,NOWRT,
NOVEC, MOD
80000030 8000003F 00000010 ( 16.)
<Linker> Q-00000000 00000000 00000000 OCTA 4
80000030 8000003F 00000010 ( 16.)
..eh_frame Q-00000000 00000000 00000000 QUAD 3 CON,REL,LCL,NOSHR,NOEXE,NOWRT,
NOVEC, MOD
80002000 8000206F 00000070 ( 112.)
vms-hello Q-00000000 00000000 00000000 QUAD 3
80002000 8000202F 00000030 ( 48.)
<Linker> Q-00000000 00000000 00000000 QUAD 3
80002030 8000206F 00000040 ( 64.)
..eh_frame_hdr64 Q-00000000 00000000 00000000 LONG 2 CON,REL,LCL,NOSHR,NOEXE,NOWRT,
NOVEC, MOD
80002070 80002093 00000024 ( 36.)
<Linker> Q-00000000 00000000 00000000 LONG 2
80002070 80002093 00000024 ( 36.)
$LINKER GOT64$ Q-00000000 00000000 00000000 QUAD 3 CON,REL,LCL,NOSHR,NOEXE,NOWRT,
NOVEC, MOD
80004000 8000400F 00000010 ( 16.)
<Linker> Q-00000000 00000000 00000000 QUAD 3
80004000 8000400F 00000010 ( 16.)

Key for special characters above
+----------------------+
! Q - Quad Value !
+----------------------+

+-----------------+
! Symbols By Name !
+-----------------+

Symbol Value Symbol Value Symbol Value Symbol
Value
------ ----- ------ ----- ------ ----- ------
-----
ELF$TFRADR 80000000-RQ

Key for special characters above
+----------------------+
! * - Undefined !
! (U) - Universal !
! R - Relocatable !
! X - External !
! C - Code Address !
! WK - Weak !
! UxWk - Unix-Weak !
! Q - Quad Value !
+----------------------+

And here's the link map for the Pascal version:

+---------------------------+
! Object and Image Synopsis !
+---------------------------+

Module/Image File Ident Attributes Bytes Creation Date Creator
------------ ---- ----- ---------------- ----- ------------- -------
HELLO 01 156 07-Nov-2023 09:35 VSI Pascal x86-6
4 X6.3-139
DISK$X86DATA:[home.jhamby.Projects]hello.OBJ;1
LIBRTL X01-001 0 30-SEP-2023 07:11 Linker I02-94
SYS$COMMON:[SYSLIB]LIBRTL.EXE;1
SYS$PUBLIC_VECTORS X-3 Sel 0 16-MAY-2023 13:31 Linker I02-94
SYS$COMMON:[SYSLIB]SYS$PUBLIC_VECTORS.EXE;1

Key for Attributes
+------------------------------------------+
! Sel - Module was selectively searched !
+------------------------------------------+

+------------------+
! Cluster Synopsis !
+------------------+

Cluster Match Majorid Minorid
------- ----- ------- ----------
DEFAULT_CLUSTER
LIBRTL LESS/EQUAL 1 1
SYS$PUBLIC_VECTORS EQUAL 14443 2200863325

On Tuesday, November 7, 2023 at 11:34:01 AM UTC-8, Jake Hamby wrote:
>
> I suspect the fix is as simple as a slightly different declaration for my code segment or the ELF$TFRADR global symbol. The nice thing about using Pascal instead of C for comparison is the Pascal version isn't pulling in any runtime support libraries, and its ELF$TFRADR is pointing at the start of the procedure code. So the linker mapping looks like the only relevant difference. I also wrote a MACRO-32 version and that looked essentially the same as the Pascal version, except with more pushing and popping of (unused) temp registers to the stack.

I posted to the VSI Forum about my problem and got back a solution almost immediately. The magic line I needed to add:

..type ELF$TFRADR, @function

Simon's right about the code I posted declaring the 64-bit descriptor incorrectly. The "must be -1" field must be a .long and not a .word. After fixing that issue and adding the line above, it all works now.

On 07/11/2023 23:18, Jake Hamby (Solid State Jake) wrote:
> On Tuesday, November 7, 2023 at 11:34:01 AM UTC-8, Jake Hamby wrote:
>>
>> I suspect the fix is as simple as a slightly different declaration for my code segment or the ELF$TFRADR global symbol. The nice thing about using Pascal instead of C for comparison is the Pascal version isn't pulling in any runtime support libraries, and its ELF$TFRADR is pointing at the start of the procedure code. So the linker mapping looks like the only relevant difference. I also wrote a MACRO-32 version and that looked essentially the same as the Pascal version, except with more pushing and popping of (unused) temp registers to the stack.
>
> I posted to the VSI Forum about my problem and got back a solution almost immediately. The magic line I needed to add:
>
> .type ELF$TFRADR, @function
>
> Simon's right about the code I posted declaring the 64-bit descriptor incorrectly. The "must be -1" field must be a .long and not a .word. After fixing that issue and adding the line above, it all works now.

So now Goodbye world?
:)

--
Chris

On Tuesday, November 7, 2023 at 3:46:05 PM UTC-8, Chris Townley wrote:
> > Simon's right about the code I posted declaring the 64-bit descriptor incorrectly. The "must be -1" field must be a .long and not a .word. After fixing that issue and adding the line above, it all works now.
> So now Goodbye world?
> :)

You know, I learned something today. A few things, actually. :)

By design, VMS's close adherence to the AMD64 ABI is going to make porting programs that generate JIT code much easier than it could've been. The nightmare I dealt with a few years ago, as part of yet another hobby distraction, was 64-bit PowerPC Linux. It's the only ELF architecture I know of where the version 1 was so relatively bad that the stakeholders all collectively went with a cleaner ELFv2 ABI with e.g. direct function pointers instead of function descriptors and a few other changes to make it less like AIX and more like the 32-bit PowerPC ABI.

At the same time, IBM and the Linux distros switched over to little-endian, for ease of porting, so now there's a "ppc64le" that uses ELFv2 and the original "ppc64" which can use either ELFv1 or ELFv2. But you can't keep them both on the same system at the same time because the shared libraries have to be one or the other.

This is how I know how painful it can be if an OS ABI diverges from the norm, whatever it is. All the ppc64 specific code had to be modified to look at big-endian vs. little-endian and also which version of the 64-bit ELF ABI you're compiling for. The shared libraries can't interoperate either, so your Linux install has to be one or the other. Statically-compiled executables can run on any kernel, but very few programs are statically linked. So it pays to get things right the first time.

Some other things I learned: VMS Pascal is probably the nicest supported language if you want to be able to access native VMS APIs with the least hassle, have the fewest dependencies on an RTL ("Hello world!" using VMS calls doesn't even need PAS$RTL.EXE, and still be able to do all the unsafe pointer arithmetic we all know and love from C. I wonder how tricky it would be to try to mechanically convert Ada 83 programs into VSI Pascal. It'd be the cleanest fit, not generated C code.

Conversely, MACRO-32 code is especially ugly on x86-64 because it has so few registers and therefore by necessity there's a thread-local pointer to an Alpha register block that's used to pass parameters around for MACRO code that assumes an argument pointer and VAX stack layout. I learned that the hard way, figuring out why "The Halls of ZK" wasn't working. I wouldn't be surprised if there aren't a number of hot code paths in the VMS executive that were never an issue for Alpha or Itanium that are now in need of being rewritten because they're passing too many values in fake Alpha registers instead of natively.