On 09/10/09 16:21, Ralph Corderoy wrote:
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.
Just rpcemu as far as I know, but I don't know much about allegro.
...
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.
No, that one really is from allegro. It's a bit odd that it only happens
under valgrind though, and that it is apparently related to
some assembly code in allegro.
The obvious conclusion would be a mistranslation of some obscure x86
instruction in valgrind, but that would be very unusual indeed these days.
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?
No, if you hit that you'll get an error from valgrind like the one I
quoted in the bug.
I suspect that whatever the allegro issue is only happens on x86 and I
was trying on a 64 bit machine with 64 bit builds of allegro and rpcemu
so if it is something in some assembly code in allegro then it is
probably different on 64 bit.
I'll try and build a 32 bit version over the weekend and see if I can
work out what the problem is.
Tom
--
Tom Hughes ([email protected])
http://www.compton.nu/
_______________________________________________
Rpcemu mailing list
[email protected]
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
