I've managed to run a native testsuite on my nslu2, I can email the tarball if anyone is interested (I think the mailing list will reject it).

There are a couple of backtraces also in the longlog, which I attach, too. Not sure if it is helpful.

I spotted some asm in ossysc.inc that will not work on eabi:

swi syscall_nr_sigreturn (same for rt_sigreturn)

For eabi this should probably be:

mov r7,syscall_nr_sigreturn
swi #0x0

But should r7 saved before and restored afterwards? I don't know how to test this code.

Thanks

Henry

Henry Vermaak wrote

I've managed to run a native testsuite on my nslu2, I can email the tarball if anyone is interested (I think the mailing list will reject it).

Is it different from the tarball you attached to http://bugs.freepascal.org/view.php?id=14386 ? I already imported that one into the testsuite database: http://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?action=1&run1id=42245&run2id=&noskipped=1&failedonly=1

There are a couple of backtraces also in the longlog, which I attach, too. Not sure if it is helpful.

Not really.

There is no "afterwards" for a sigreturn system call, as it restores the context that was saved when the signal was triggered (so code coming after the swi is never executed, except possibly in case of an error that didn't crash the program).

I don't know how to test this code.

You normally never need to explicitly use this system call. The kernel usually puts a stub somewhere in memory containing this system call and makes the return address of signal handlers point to that stub.

Jonas

2009/8/22 Jonas Maebe :

Yes, this time I ran the testsuite natively, so I think a lot more of the tests have run (and passed), consequently taking much longer (3.5 hours). I guess the same tests would have failed again, so maybe there's no use.

This run also includes the sigreturn patch below.

Thanks for the explanation. I guess the DoSyscall function can then be used instead of this assembler code? Then there won't be yet another ifdef here.

Henry