Re: XCAR/XCDR as lvalues
On Thu, Jan 21, 1999 at 05:10:21PM +0100, Hrvoje Niksic wrote:
Then how come I can't get a crash out of X[AC]DR being an
lvalue?
Kyle reported that this got hosed when we started using ELF-style
binaries. Can someone who understands these things elaborate?
Elf uses more than the usual text/data/bss separation. It has a first
level of program headers, like:
Program Header:
PHDR off 0x00000034 vaddr 0x00010034 paddr 0x00000000 align 2**0
filesz 0x000000a0 memsz 0x000000a0 flags r-x
INTERP off 0x000000d4 vaddr 0x00000000 paddr 0x00000000 align 2**0
filesz 0x00000011 memsz 0x00000000 flags r--
LOAD off 0x00000000 vaddr 0x00010000 paddr 0x00000000 align 2**16
filesz 0x001a3602 memsz 0x001a3602 flags r-x
LOAD off 0x001a3604 vaddr 0x001c3604 paddr 0x00000000 align 2**16
filesz 0x0024d9fc memsz 0x0024d9fc flags rwx
DYNAMIC off 0x001a3620 vaddr 0x001c3620 paddr 0x00000000 align 2**0
filesz 0x00000130 memsz 0x00000000 flags rwx
these define the read, write and execute properties.
Then this is sub-segmented into sections:
Sections:
Idx Name Size VMA LMA File off Algn
[...]
8 .text 00150814 000428dc 000428dc 000328dc 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
9 .init 0000001c 001930f0 001930f0 001830f0 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
10 .fini 00000014 0019310c 0019310c 0018310c 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
11 .rodata 000202e8 00193120 00193120 00183120 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
12 .rodata1 000001fa 001b3408 001b3408 001a3408 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
13 .got 0000001c 001c3604 001c3604 001a3604 2**2
CONTENTS, ALLOC, LOAD, DATA
14 .dynamic 00000130 001c3620 001c3620 001a3620 2**2
CONTENTS, ALLOC, LOAD, DATA
15 .plt 00001540 001c3750 001c3750 001a3750 2**2
CONTENTS, ALLOC, LOAD, CODE
16 .data 000caead 001c4c90 001c4c90 001a4c90 2**3
CONTENTS, ALLOC, LOAD, DATA
[...]
These readonly properties aren't enforced by the os. Only the ones in
the program header are. To make the purespace readonly we'd need to
extend the readonly program header to cover the .data section (we
can't simply add one, the alignment constraints are drastic). This
would also make the .got, .dynamic and .plt sections readonly.
Instant segfault.
As a side effect the "initialized globals variables are readonly after
dumping" rule isn't required either, given that the pre-elf dumpers
were simply expanding the text section over the data section and
mutating the bss into a data one.
Kyle reported that BSD/OS uses a read-only purespace.
Mysterious segmentation faults on BSD/OS, film at 13. This is one
crash cause I'd happily do without.
Anyway, I think
you are misusing the word "require". In my opinion, read-only
purespace is a *feature*. We want the purespace to be shared. In
this case, we *don't* want the mythical COW.
Don't write, then.
Face it, purespace sucks. It doubles the dump time and is pure
nonsense with moderm systems which _do_ share pages without the need
for it, thankyouverymuch. Now what we may like to have is a readonly
attribute. This will need gung-ho in order to have space for the
flag, and an external, generational GC should keep the memory access
patterns happy. And a test in each in-place setting operation...
OG.