Re: [Sbcl-devel] [Fwd: Re: sbcl for mips/mipsel]

[Christophe R. <cs...@ca...>]

Thiemo Seufer <th...@ne...> writes:

> Christophe Rhodes wrote:
> [snip]
>> One thing you could do, I think, is to run under gdb with a breakpoint
>> on os_flush_icache.
>
> Bingo. On mips the generated code seems to reside in 0x08000000, which
> gets flushed, and in 0x01000000, which doesn't trigger a cache flush.
>
>>From mips/parms.lisp:
> (def!constant read-only-space-start #x01000000)
> ...
> (def!constant dynamic-space-start   #x08000000)

Um, but, but... it's called read-only-space for a reason!  Under
normal operation, very little should be writing there (the exception
is the purify() machinery).

Hmm, OK: what about calling mprotect() from gdb after starting up the
core, to protect the read-only-space from writes?  If anything _does_
write to that space, this should trigger the lisp debugger from which
it should be possible to backtrace and find out what is actually
trying to write there.  (I have to say, I can't see what would do so,
but stranger things have happened: nothing that I can see touches
*read-only-space-free-pointer*)

> So it seems some (dump-fop 'fop-sanctify-for-execution file) is missing
> in dump.lisp. I can't make sense of the dump-* functions there, I guess
> it's one of the fasl-dump-* called from main.lisp.

This is entirely possible.

Cheers,

Christophe