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)