Eric Schwartz wrote:
>
> I was working on <URL:http://bugs.debian.org/140153>,
Ok, what happens is that Gforth uses sigaction() to install a signal
handler for SIGSEGV called segv_hanlder() (look it up in
engine/signals.c). This signal hanlder is called when we do an
ordinary segmentation violation, as in
0 @
or with kill -11. But when we try to execute unaligned code, this
signal handler is not entered as far as I can determine (I checked
using gdb breakpoints, as well as by inserting fprintf statements).
I tried to reproduce the problem in a simple C program:
#include <signal.h>
#include <unistd.h>
#include <stdio.h>
void handler(int sig)
{
fprintf(stderr,"my signal handler caught signal %d\n",sig);
exit(sig);
}
int main()
{
signal(SIGSEGV, handler);
start:
goto *((&&start)+1);
}
The loop beginning at "start:" looks like this:
0x100004dc <main+28>: lis r9,4096
0x100004e0 <main+32>: addi r9,r9,1245
0x100004e4 <main+36>: mtctr r9
0x100004e8 <main+40>: bctr
What happens when I step through it with gdb I see that 0x100004dd is
loaded into cnt (ctr), then the bctr is performed, and execution
continues at 0x100004dc; so something corrects the alignment error in
this case, and the signal handler is not invoked. Hmm.
Ok, I also checked if the problem in Gforth has to do with the unusual
linkage options ("-Xlinker --script=./arch/power/elf32ppc.x"), but
disabling that (only possible for indirect threaded code) does not
help.
I think there is something very funny going on, and someone familiar
with signal handling on Linux/PPC should take a look at it.
For the Gforth port itself this is not a big issue, as David Williams
pointed out (you can do things in Forth that are much worse).
- anton
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
