[Info-vax] Tales From The Port

[John Reagan]

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