[Info-vax] Tales From The Port

[gezelter at rlgsc.com]

On Tuesday, April 16, 2019 at 4:30:16 AM UTC-4, John Reagan wrote:
> While we're waiting on Clair's next boot update, I'll share our latest Macro-32 bug so you can you some of the day-to-day bugs we're dealing with.
> 
> [This is a cut-down bug from inside of DCL]
> 
> For the following Macro-32 code,
> 
>         .psect $data$,rd,nowrt,noexe
> one:    .ascii /A/<0>
>         .ascii /Z/
> 
> two:    .ascii /A/
>         .byte 0
>         .ascii /Z/
> 
> three:  .ascii /A/
>         .blkb 1
>         .ascii /Z/
> 
>         .end
> 
> The $DATA$ psect should be 9 bytes long(as seen on Itanium)
> 
> SECTION DATA 4. (0004)                       SHDR$K_SHT_PROGBITS 0000000000000009 (9.) bytes
> "$DATA$"
>                                                                                                            
> 5A 00415A00 415A0041  A.ZA.ZA.Z
> 
> but on x86, it is only 8 bytes.  That <0> syntax was lost by the compiler.
> 
> SECTION DATA 4. (0004)                       SHDR$K_SHT_PROGBITS 0000000000000008 (8.) bytes
> "$DATA$"
>                                                                                                            
> 5A00415A 00415A41  AZA.ZA.Z
> 
> 
> The GEM interface lets the Macro compiler say "Put a A at $DATA+0, Put a Z at $DATA+2".  The order isn't important either.  The abstraction is that you are putting values into the PSECT and the unspecified holes end up being zeros.  The LLVM interface is a "call it like you are writing out an assembly source file".  The compiler has to buffer up the initializers and then call LLVM in the right order and with additional calls to insert/skip holes.  The internal representation for the <0> surprised us and we didn't skip/initialize the byte.  
> 
> This malformed data (imagine if this was some sort of NUL-terminated string) made DCL unhappy and DCL is a pretty grumpy piece of code to start with.
> 
> 
> John

John,

Ah, the joy of "the devil is in the details". I remember more than a few of those when converting from one interface to another. Sometimes, things are described in similar ways, but are in actuality quite different.

I would think that items of this type are fairly common in more than a few sections of the MACRO-32 source, particularly within macros.

I remember many occasions where I encountered code along the lines of:

XYZ: 
        .REPEAT 256
        .WORD 0
        .ENDR

$$$ = .
. = XYZ+nn
        .WORD ccc
. = $$$

The idea being to set up a table with default actions, and then fill in specific entries.

Most system call macros on OpenVMS generate stack-based parameter lists, but I would not be surprised to find constructs like the above in macros that generate control blocks.

Such "back patching" was a common coding trick in many assembler languages, not just within Digital.

- Bob Gezelter, http://www.rlgsc.com