[Gambas-user] Issue 226 in gambas: SIGSEGV handler overwritten (for too long)

[gambas at ...2524...]

Comment #5 on issue 226 by x1F3O3X7x at ...626...: SIGSEGV handler overwritten  
(for too long)
http://code.google.com/p/gambas/issues/detail?id=226

A few advantages of having the xbox emulator and the debugger in the same  
process:

- Almost full control over dynamicly linking the emulator to keep certain  
memory areas free during testing (necessary to emulate MMIO areas which  
have a fixed address).
- Structures like trees and lists can be used easily because all pointers  
are still valid. (http://jannikvogel.de/screenshots/1332535865-2.jpg - a  
tree drawn directly from memory [image taken with a CPU interpreter active  
which doesn't require SIGSEGV handling])
- Huge memory dumps are possible because no memory has to go through pipes  
or via ptrace functions.
- The emulator functions can easily be exported and called by the debug  
environment without any major changes to the emulator.
- No code for the debug interface must be written, only functions which  
should be available to the debugger must be marked.
- The emulator has a launcher which uses the same set of functions, so this  
is essentially testing the application in a release configuration.
- No linux or windows (The emulator is cross-platform with a tiny  
abstraction layer for every platform) specific code must be added for the  
debug interface.

I believe that removing the siglongjmp won't be enough. I assume that the  
problem is that the SIGSEGV handler is simply installed for too long (on a  
multi-processor system it's ALWAYS too long).
So to avoid the problem the signal handler should not be installed at all.
I tried to use make-component to make my own gb.unsafe but I couldn't get  
it to work properly. Is there any way to overwrite the  
original "Integer@()" etc. functions with my own component? Or is it at  
least possible to have global functions in components? (I wouldn't want to  
write something like "_.Integer@()", which I use at the moment. Even less  
something like "unsafe.Integer@()" - it would just make the code longer and  
confuse others)