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. I ended up static-linking the
> binary so I could disassemble the code with GDB...:
>
> 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 writing the immediate value 0x80000004 into register %d0. All
that is, is setting up the final register argument for the "trap".

It's evidently choking in the trap.

> On the other paw, the entire function looks like syscall magic
> anyway...

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.


Frederick