Re: [Gambas-user] Issue 226 in gambas: SIGSEGV handler overwritten (for too long)
Brought to you by:
gambas
From: <ga...@go...> - 2012-03-29 17:10:17
|
Comment #5 on issue 226 by x1F...@gm...: 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) |