site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com The official Apple position is a question best directed to DTS. Please do; that was the specific intent of sigsetjmp/siglongjmp. If you don't see this, please file a bug. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Nov 22, 2008, at 11:56 AM, Jonas Maebe <jonas.maebe@elis.ugent.be> wrote: [ ... ] @OSF_COPYRIGHT@ The base intent of strings of this format in source code us to cause source code control systems to insert/replace the text with source code known to the sccs at check-in time. Given that our current sccs checkin scripts do not reprocess a number of tag string like $Id:$ and this one, it would be my completely unofficial guess that the copyright boiler-plate for the file was copied from the corresponding x86 file, and that was left in accidently (_struct.h in x86 and ppc are new works by Ed, myself, and others as part of cleaning up namespace issues for UNIX conformance). I'd also like to point out from a signals perspective that the contents of the sigcontext and mcontext are supposed to be opaque, and other than their size, unless you are a debugger, you should not be introspecting their contents. If you are not a debugger, then you should be trying to write your code in such a way that not even the size matters outside of libc itself to let the structures change out from under you without breaking your code, if at all possible. I have tried that when I did the initial port to Mac OS X, 5 years ago or so, and failed. The situation is currently like this: 1) an fpu exception, or sigsegv, sigbus, ... occurs 2) the OS raises a mach exception, which is then converted into a unix/bsd signal 3) we catch the signal using a handler installed at startup of the app 4) we determine the nature of the signal and where it occurred 5) we change the context of the signal (here's where we need the structures) so that it will return to our own run time error handler. We also store the necessary information (exception nature, pc where it occurred, stack pointer at the exception time) in some register fields of the context struct (which are interpreted as parameters in the run time error handler) 6) we return from the signal handler 7) the kernel resumes execution in our run time error handler 8) we generate the appropriate language exception My initial version used some form of (sig)longjmp instead of steps 5 to 7 to hand over control to our run time system, but that does not work for fpu exceptions (at least not on PPC). The reason was that as long as you did not return from a signal handler, fpu exceptions remained disabled (well, you could re-enable them in the fpscr, but the kernel dropped them on floor as soon as they occurred again afterwards). I can't immediately find again where this happens in xnu, but if you are interested I could try to look it up again. Assuming the sigsetjmp happened prior to the signal handler, I would expect the mask state to be restored on siglongjmp. If it is not, I'd class that as a bug (NOTE: not a bug if you are using {set|long}jmp instead of sig{set|long}jmp). I'm not sure what alternatives I have to convert hardware/OS exceptions into language exceptions (at least not if I want to be able to provide backtraces to the consumers of those exceptions, like we do right now. You could always take and eat the Mach exception sent to your task, prior to it being converted into an AST and then into a signal. This email sent to site_archiver@lists.apple.com