porting privileged code MBMON

[imiller]

I'm having a go at porting my MBMON freeware. This includes a UWSS and a loadable executive image for added fun.
It is written in C on Alpha VMS years ago and can be found in the usual OpenVMS freeware collections

To load the executive image it calls ldr$load_image ( documented here https://docs.vmssoftware.com/vsi-openvm ... i/#LI_SEC ) and that is returning SS$_ACCVIO which according to the documentation means "Unable to read the character string descriptor containing the file name of the executive image to be loaded or to write the reference handle." I've checked the variable for the reference handle is writable.
The character string descriptor is declared the usual fashion with the $DESCRIPTOR macro

Code: Select all

#define MBMON_EXECLET_NAME "MBMON_EXECLET"
...
static $DESCRIPTOR(execlet_dsc,MBMON_EXECLET_NAME);

Has anyone used ldr$load_image on x86 or I64 successfully or could suggest why SS$_ACCVIO is being returned?

[hb]

Has anyone used ldr$load_image on x86 or I64 successfully or could suggest why SS$_ACCVIO is being returned?

Yes, but no. I don't know where your ACCVIO is coming from.

Code: Select all

$ write sys$output f$getsyi("arch_name")
x86_64
$ ! A recent version, but the version should not matter.
$
$ pipe write sys$output "show exec miniexeclet" |analyse/sys

OpenVMS system analyzer

No loadable image matching "MINIEXECLET" found
$ 
$ mms

CC /standard=relaxed/list LDIMG.C +sys$share:sys$lib_c.tlb/lib
CC /standard=relaxed/list MINIEXECLET.C +sys$share:sys$lib_c.tlb/lib
LINK /TRACE/NOMAP/EXEC=MINIEXECLET.EXE MINIEXECLET.OBJ
LINK LDIMG/sysexe
define/job SYS$LOADABLE_IMAGES sys$disk:[],SYS$SYSROOT:[SYS$LDR]/nolog
$ run ldimg
$ 
$ pipe write sys$output "show exec miniexeclet" |analyse/sys

OpenVMS system analyzer


VMS Executive layout
--------------------

Image                                         Base               End             Length         Image Offset     SymVec
--------------------------------------- ----------------- ----------------- ----------------- ----------------- -----------------
MINIEXECLET                            
    Data (read/write)                   FFFFFFFF.804C2000 FFFFFFFF.804C2007 00000000.00000008 00000000.00002000
    Code                                FFFF8300.06C2FD00 FFFF8300.06C2FD0A 00000000.0000000B 00000000.80000000
    Unwind tables                       FFFF8300.06C31D00 FFFF8300.06C31D4B 00000000.0000004C 00000000.80002000
    Code                                FFFFFFFF.8A975C00 FFFFFFFF.8A975C83 00000000.00000084 00000000.00004000
        Linked  7-JUN-2024 21:24        LDRIMG = 820E9940 SeqNum = 00000076 

$ 

>If you wish to attach one or more files enter the details below. You may also attach files by dragging and dropping them in the message box.

I want to upload/attach files from VMS, how do I do this?

[arne_v]

I have never used that function.

But it seems to be that it is way more likely that the problem is related to "to write the reference handle" than "to read the character string descriptor containing the file name of the executive image to be loaded".

So what are you passing for reference handle?

The address of 3 longwords?

[hb]

Ian didn't show the sources. The sources I can find are from 2006. It seems the build scripts are for Alpha only. Although I tried, it's probably not worth the time with these sources. I gave up very quickly.

It may be the handle and the check if it is writeable or not. LDR$LOAD_IMAGE returns 0x0C, that's all - no address, no indication if there was a real ACCVIO or just a PROBE and for what address and/or READ or WRITE. It is obviously a simple interface intended for internal use.

And I hope Ian didn't pass an address of three longwords. He should know better.

Although the documentation referred to claims:

Publication Date: June 2024

Operating System and Version:
VSI OpenVMS IA-64 Version 8.4-1H1 or higher
VSI OpenVMS Alpha Version 8.4-2L1 or higher
VSI OpenVMS x86-64 Version 9.2-1 or higher

But the pointed to section says:

4.7.2.4. LDR$LOAD_IMAGE (Alpha or I64 Only)

. So this is obviously somehow out of sync, incomplete or not really updated for x86-64.

Apparently no one can tell me how to attach a file to a post on this board using cURL on VMS. So I went the extra mile and downloaded from VMS to a non-VMS system and uploaded from there.

That didn't work: "Error, Invalid file extension: descrip.mms". This is a forum/board for VMS related stuff, right? I zipped the files.

[arne_v]

And I hope Ian didn't pass an address of three longwords.

The linked docs say:

Code: Select all

The longword address of a reference handle, a three-longword buffer to be filled by LDR$LOAD_IMAGE as follows:

+00 Address of loaded image or zero if image was loaded sliced.
+04 Address of loaded image data block (LDRIMG). See the $LDRIMGDEF macro definition in SYS$LIBRARY:LIB.MLB and VMS for Alpha Platforms Internals and Data Structures for a description of the LDRIMG structure.
+08 Loaded image sequence number.

But a quick look at LDRHDL from ldrimgdef.h reference din your C code does say 2 x quadword + 1 x longword aka 20 bytes.

[hb]

The handle has changed for x86. It is highly recommended to use the LDRHDL type (and as far as I know, Ian is aware of this). This type is not mentioned in the referenced documentation. Again, the documentation is outdated!

If someone is using three longwords, it is very likely that some data is corrupted/overwritten. The x86 compilers pack the data very efficiently. Other VMS compilers usually align the data to longword or quadword boundaries. This is forgiving if you have the wrong size for data passed by address to other functions. There was a customer who claimed that there was a problem in the x86 VMS code - because his program worked for over 30 years on VAX, Alpha, and I64. He was wrong, his code was wrong, all the time. He passed an address of a longword where the system service expected the address of a quadword. On all systems the next longword was overwritten, but only on x86 a variable was overwritten. And so only on x86 the system service returned a wrong result.

[arne_v]

Is the 32 to 64 bit change due to execlets moving from S0 to S2? Or for other reasons?

[imiller]

thanks for the helpful comments. I will review them and see what can be done.
The public sources are the Alpha VMS version I wrote back in 2005. When I get the time, I'm working to update this to make it work on OpenVMS I64 and x86 which means dealing with the 32-to-64-bit changes as well as the different architectures.
Executive images and User Written System Services are only briefly documented so this sort of thing requires some trial and error sometimes. I'm familiar with system programming on VMS which I mostly do for fun nowadays as my day job is mostly VMS Management.
I'm mostly working on x86 because that's my hobbyist system and I can crash it with nobody minding. I have access in my day job to Alpha and I64 systems but must be more careful with those.

[imiller]

I got a little time on this and discovered I'd not quite done all the fixup for 64-bit addresses,
I only get to play around with this stuff occasionally and leave myself notes to remind myself what i was doing and sometimes forget things.
I have the execlet loading and unloading OK now but curiously this only works if I call routines using SYS$CMEXEC/CMKRNL so there's something wrong with my UWSS setup which I will have to fix next.