• domain_os.map format q

    From toshok@gmail.com@21:1/5 to All on Thu Sep 7 10:26:37 2023
    (Probably a question for Jim, but maybe there are others around that might have some memory buried someplace)

    This file has been _invaluable_ to decompiling the kernel, but I have some questions about the original tooling that apollo used to build domain_os (and emit this file).

    Take the following snippet from sr10.4 /sau11/domain_os.map:
    ========
    D 7A42E00C AST_ size = 284
    7A42E00C AOTH
    7A42E0D4 AST_$AST_IN_UPDATE_EC
    7A42E0E4 AST_$AST_IN_TRANS_EC
    7A42E0F0 AST_$SHADOW_FLT_CNT

    .....

    I 7A423BF0 UID_$HASH size = 1C
    7A423BF0 UID_$HASH
    I 7A423C0C UID_LIST size = 230
    7A423C0C UID_$NIL
    7A423C14 ACL_$NIL
    7A423C1C PV_LABEL_$UID
    7A423C24 LV_LABEL_$UID
    ========

    the lines with "D/I .... size = ..." look to define regions of data and code respectively, with every entry after them that type - "I" = everything is functions, "D" = everything is data. But the type for UID_LIST looks wrong. Those are storage
    locations for the individual 8 byte UIDs/ACLs, not functions.

    Given that this one is wrong, and the vast majority are correct (I haven't noticed another incorrect one) I'm assuming human error, which leads to my question: how were these regions defined? was there a pair of compiler directives to denote begin/end?
    was the region name based on the file name?

    I've read through the "DOMAIN Binder and Librarian Reference" up on bitsavers, and that does hit on some things - e.g. "MARKED" as applied to data symbols looks like it matches the behavior documented there. But I don't see anything about those region
    lines.

    -c

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)