4:10 p.m.
Jan Vroonhof <vroonhof(a)math.ethz.ch> writes:
Hrvoje Niksic <hniksic(a)srce.hr> writes:
> I don't know if we do.
We do (at least it seems so from lisp.h).
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?
(Please avoid the "copy-on-write" syntagm in the elaboration -- I'm
alergic. :-)
> > They do COW don't they?
>
> Isn't it a better policy to keep the shared segments read-only?
Unexec'ing puts the pure stuff the .data segment if I am not
mistaken:
[...]
Quite possible, but this might also be considered a bug.
So the question is now: Is XEmacs used at all on platforms which do
require a true read-only purespace.
Kyle reported that BSD/OS uses a read-only purespace. 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.
6:36 p.m.
New subject: 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.
8:49 p.m.
New subject: XCAR/XCDR as lvalues
Hrvoje Niksic writes:
Jan Vroonhof <vroonhof(a)math.ethz.ch> writes:
> So the question is now: Is XEmacs used at all on platforms which do
> require a true read-only purespace.
Kyle reported that BSD/OS uses a read-only purespace. 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.
As Olivier mentioned, the pages should be sharable so ong as
we don't write to them. But this means that we can't run the
mark-sweep GC over read-only objects. Once the objects have
been marked, poof, no more shared pages. But this is OK,
because we really don't want to GC these objects anyway, and
we might as well save time by not looking at them during GC.
The fact that read-only objects can't be GC'd also happens to be
the reason why the read-onlyness of these objects needs to be
enforced by the OS. If it isn't enforced, we can get crashes.
Example: If a supposedly read-only Lisp cons is modified to
contain a reference to a normal read-write Lisp object, the GC
won't see that reference. If there are no other reference to
the read-write object, it will be collected. We'll crash later
if we use the still-existing reference to the collected object
that exists in the read-only object.
In summary, if we want shared dumped pages, we can't GC the shared
objects. And if we can't GC the objects, the read-onlyness of the
object needs to be enforced to prevent weird GC related crashes
down the road.
9441
days inactive
9441
days old
2 comments
3 participants
participants (3)
-
Hrvoje Niksic -
Kyle Jones -
Olivier Galibert