If you do "cs161-objdump --all-headers" on one of the userlevel
programs for OS/161, and look at the "program headers" (this is what
you use to load the program) you'll discover it looks something like
this:
Program Header:
LOAD off 0x000000b4 vaddr 0x00001000 paddr 0x00001000 align 2**2
filesz 0x00001708 memsz 0x00001708 flags r-x
LOAD off 0x000017c0 vaddr 0x00002720 paddr 0x00002720 align 2**3
filesz 0x00000937 memsz 0x00000937 flags r--
LOAD off 0x000020f8 vaddr 0x00003058 paddr 0x00003058 align 2**2
filesz 0x000000cc memsz 0x000000cc flags rw-
LOAD off 0x000021c8 vaddr 0x00003128 paddr 0x00003128 align 2**3
filesz 0x00000000 memsz 0x00000210 flags rw-
You'll see that the read-only part (code and read-only data) stops at
virtual address 0x3057, and the read-write part starts at virtual
address 0x3058.
Note that this is not a page boundary.
What this means is that without tweaking the linker, you won't be able
to make the last page of the read-only segments read-only without
breaking the read-write segments.
We don't require that you make the read-only segments actually
read-only (as long as writing to them does not corrupt the executable
files or other concurrently running copies of the same program.)
If despite this problem you still want to, you should be able to tweak
the linker by adding "-Tdata 0x01000000" to the linker flags (LDFLAGS)
for userland. (The best place to do this is in src/mk/prog.mk.) This
will cause the linker to start the read-write data at virtual address
0x01000000 instead of immediately after the read-only data.
Theoretically, it should be possible to get the linker to output the
read-write data immediately after the read-only data, but page-aligned
so as to make it possible to protect it differently. However, it
involves detailed fiddling with linker scripts and probably isn't
worthwhile.
Your system may reject executables where the read-only and read-write
portions overlap (as long as it runs the executables you compile for
it.) However, it should, preferably, not assume that code and data are
contiguous.
--
- David A. Holland | VINO project home page:
dholland(a)eecs.harvard.edu |
http://www.eecs.harvard.edu/vino