At 20:04 Uhr +0200 28.3.2001, Frederick Bruckman wrote:
>On Wed, 28 Mar 2001, Nyef wrote:
>
>> On Wed, 28 Mar 2001, Hauke Fath wrote:
>>
>> Well, it looks like the right function, and I think I'm calling it right,
>> but it's segfaulting every time I run it.

The parameters you call  m68k_sync_icache() with describe a vm region
which, of course, must be accessible. Otherwise, a segfault is exactly what
I'd expect.

>> Program terminated with signal 11, Segmentation fault.
>> #0  0xaef8 in m68k_sync_icache ()
>> (gdb) disas
>> Dump of assembler code for function m68k_sync_icache:
>> 0xaef0 (m68k_sync_icache):      movel %sp@(8),%d1
>> 0xaef4 (m68k_sync_icache+4):    moveal %sp@(4),%a1
>> 0xaef8 (m68k_sync_icache+8):    movel 0x80000004,%d0
>> 0xaefe (m68k_sync_icache+14):   trap #12
>> 0xaf00 (m68k_sync_icache+16):   rts
>> 0xaf02 (m68k_sync_icache+18):   orib #86,%d0
>> End of assembler dump.
>> (gdb)
>>
>> The absolute address in the movel instruction at 0xaef8 kinda worries me,
>> since I don't know what it's doing...

It's a function number. Look in /sys/arch/mac68k/mac68k/locore.s for the
"lower half" of the syscall (identifier trap12).

>I suspect your program is actually trying to execute the trap (while
>the processor is in user mode), rather than doing the syscall dance
>(which would switch the processor into supervisor mode). Of course, if
>anybody succeeds in calling m68k_sync_icache() from a program, that
>would blow my theory away.

ISTR the trap itself provides for a transition to supervisor mode.

Actually, m68k_sync_icache() was a late solution for port-m68k/4951 which I
filed ages ago when I tried to get the Kaffe 0.84 JIT to work. Back then, I
inserted the moral equivalent of the above code (which could be found in
some ld(1) function) into Kaffe. So, yes, in a way I succeeded in calling
the function.  ;)

	hauke

--
"It's never straight up and down"     (DEVO)