Kaffe 0.84/JIT on netbsd-m68k (long)

[Gordon W. Ross]

> 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 2.7.2.3, at least. 2.7.2.1 had NOT valid code
> for 68040 and 60. We imported those parts of 2.7.2.3 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...

Gordon