Re: Meaning of @OSF_COPYRIGHT@
Re: Meaning of @OSF_COPYRIGHT@
- Subject: Re: Meaning of @OSF_COPYRIGHT@
- From: Terry Lambert <email@hidden>
- Date: Sat, 22 Nov 2008 12:39:44 -0800
On Nov 22, 2008, at 11:56 AM, Jonas Maebe <email@hidden>
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).
The official Apple position is a question best directed to DTS.
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.
Please do; that was the specific intent of sigsetjmp/siglongjmp.
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).
If you don't see this, please file a bug.
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.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden