Hi Tom,
> Ah. I think that's a rather unhelpful allegro message confusing you...
>
> Allegro has registered a segv handler and prints that message whenever
> the program hits a segv regardless of who causes it
Yep, got that bit.
> If you use --trace-signals=yes on valgrind you'll see that the signal
> is coming from dynamically generated code - the core problem is that
> valgrind is itself doing dynamic translation and has a cache and if
> code that it has translated changes it will not notice and it will
> execute incorrect code.
Ah, right, OK. Is Allegro doing JIT, or just rpcemu? Only re-building
without --enable-dynarec still causes valgrind act the same.
...
rpcemu: version=0.8.5 _DEBUG=no DYNAREC=no
++12558++ do_setmask: tid = 3 how = 0 (SIG_BLOCK), set = 0x58FF334
fffffffe7fffffff
--12558-- delivering signal 11 (SIGSEGV):128 to thread 1
--12558-- push_signal_frame (thread 1): signal 11
==12558== at 0x4108E0B: (within /usr/lib/liballeg.so.4.2)
==12558== by 0x40BB111: (within /usr/lib/liballeg.so.4.2)
> Ad --smc-check=all to valgrind and it will checksum each block before
> executing it and retranslate it if it has changed. That will slow
> things down a lot though.
Makes sense. But it doesn't alter things here.
> I also had to patch my way round one instruction that rcpemu is using
> in the code it generates that valgrind didn't understand as it wasn't
> the "normal" encoding for that instruction. I've raised a bug for
> valgrind to get Julian to fix that:
>
> https://bugs.kde.org/show_bug.cgi?id=209995
Could that be continuing to cause the SEGV I'm getting very early on,
before the window appears, or is it possible it's the Allegro
"assembler" issue referred to in those links in the earlier email?
Cheers,
Ralph.
_______________________________________________
Rpcemu mailing list
[email protected]
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
