Kaffe 0.84/JIT on netbsd-m68k (long)
Gordon W. Ross
gwr at mc.com
Wed Feb 4 19:12:28 PST 1998
> From: Ignatios Souvatzis <is at jocelyn.rhein.de>
> Date: Wed, 4 Feb 1998 23:11:13 +0100 (MET)
[ Need to flush the I-cache ... ]
> > *Bingo!*
> > I hacked the asm code snippet in (gcc inline assembler is ugly as hell) and
> > Kaffe 0.84 JIT compiles & runs "HelloWorldApp" now. =8)
> > On the other hand...
> > The JIT code (#define'd in jit.h) calls __clear_cache() from libgcc.a. The
> > comment says...
> > /* On the 68040 (and 060 I presume) we need to flush the instruction
> Yes :-), but also on the 68030. 256 bytes of I-Cache can be very much.
Yes, all self-modifying code should definitely flush the I-cache.
> I never understood why the sig-trampoline code gets away without doing this.
We are guaranteed that I-cache holds nothing from user-space at the
time the signal trampoline code is copied out. Does that answer?
(Is there self-modifying code elsewhere in signal delivery?)
[ How to flush the cache... ]
> > -- Is this always a no-op for NetBSD/m68k?
> > Is the routine from
> > arch/m68k/mdprologue.S globally available?
> err... at least, it should be in dynamically loaded programs, as ld.so is
> using it when patching shared library references..
Hmmm... Looks like that _cachectl code should be copied into
libgcc2.a (well, into libc in our case):
It would be nice if we could let a simple "trap #2" do the job of
flushing the I-cache as needed for self-modifying code to work.
That's what "trap #2" does on SunOS (their dynamic linker uses it).
Also it was implemented as a "fast trap" (no "rei" check, just rte)
so we could do the same and let both our executables and SunOS
enjoy the availability of a very cheap I-cache flush.
BTW, we no longer use "trap #2" for kernel breakpoints, so we
could now easily let it mean "flush the I-cache". Good idea?
> > >From looking in gcc/libgcc2.c, there seem to be more preprocessor symbols
> > than actual code so I don't exactly get what's going on. But I didn't see
> > any obvious function call or trap there.
> You should make sure to have 184.108.40.206, at least. 220.127.116.11 had NOT valid code
> for 68040 and 60. We imported those parts of 18.104.22.168 during the early
> 1.3 release branch time, just to fix that bug.
Again, gcc could just do "trap #2" on both SunOS and NetBSD...
More information about the kaffe