[Info-vax] VMS 9.2 release build completed, release approaching

[John Reagan]

On Wednesday, June 29, 2022 at 7:29:00 AM UTC-4, osuv... at gmail.com wrote:
> On Wednesday, June 29, 2022 at 5:21:02 AM UTC-4, Jan-Erik Söderholm wrote: 
> > Den 2022-06-29 kl. 10:06, skrev John Dallman: 
> > > From a VSI post on LinkedIn: 
> > > 
> > > "The candidate build was completed on 16 June, the goal is to make this 
> > > the final release for 9.2 and to ship any fixes as patch kits." 
> > > 
> > > <https://vmssoftware.com/about/news/2022-06-28-state-of-the-92-release/> 
> > >
> The notes about va_copy are interesting. Presumably, the v*printf functions in the 
> C RTL still work, so the compiler knows how to pass a va_list to another routine 
> but it can't copy it to another va_list. 
> 
Copying a va_list has always been something that should have used va_copy().
You can cheat with a direct assigment of va_list's on VAX, Alpha, and Itanium
since va_lists are just arrays of pointers.  That isn't true on x86.  A va_list is a 
struct with some fields, several pointers, and more.  You have to ask the
compiler to do that for you with the va_copy() intrinsic.  That is what every
piece of opensource code on Linux does today (or it wouldn't work).  Added
to the problem is that the va_copy from C99 was only added into the headers
by VSI.  (On Alpha & Itanium, it just expands into an assignment.  On x86, it is
a real intrinsic that we have to pass along to LLVM).

And while I'm here, please, please, please switch from <varargs.h> to <stdarg.h>
if you are still using it.  The model presented to us by LLVM is the stdarg model.
We have to do extra work to hack up varargs.

> The note on short data in IA64 protected images is a little disturbing. A protected 
> image ported to X86 may break because it was (possibly inadvertently) doing 
> something unsafe?
No, that release note just attempts to describe that unlike Itanium with had a single
short section with linker-generated address constants, there may now be multiple
GOTs (Global Offset Table) in a single image, one per cluster.  Most normal images
only have one cluster (you have to use explicit linker options to split it up).  

On Itanium, all routines get a GP (Global Pointer) passed in so a routine can find
all the address constants.  On x86, there is nothing passed in.  It has to know the
distance from the code to the GOT.  The linker-create GOT (again, one per cluster)
is another image segment at a fixed offset from the code.  If you move the code,
you have to move the associated GOT.  Nothing really unique to OpenVMS other
than perhaps having an image with some code in 64-bit space and some code
in 32-bit space. If you read the AMD64 ABI, that isn't the "small" or "medium"
or "large" memory model.  We are sorta like "medium" with some pieces from
the "large" memory model where we always go thru the GOT to find all static
data and to find other routines in the same module (but might be in different
code PSECTs).