Re: Meaning of @OSF_COPYRIGHT@
Re: Meaning of @OSF_COPYRIGHT@
- Subject: Re: Meaning of @OSF_COPYRIGHT@
- From: Jonas Maebe <email@hidden>
- Date: Sat, 22 Nov 2008 22:02:05 +0100
On 22 Nov 2008, at 21:39, Terry Lambert wrote:
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).
Ok, thanks. I guess I'll have to go for installation time conversion
in that case (unless sw licensing one day decides otherwise)...
The official Apple position is a question best directed to DTS.
I wish they (well, sw licensing) were as responsive and helpful as you
are.
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.
Ok, I'll have a look.
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.
Before I do so, here's a test program from 2004 I dug up that
demonstrates the problem (ppc-specific) -- just to make sure that I
didn't overlook anything:
#include <signal.h>
#include <stdio.h>
#include <ucontext.h>
#include <setjmp.h>
// check whether we really caught the exception
static int caught;
static sigjmp_buf env;
void signal_handler(int signum, siginfo_t *info, ucontext_t*
sigcontext) {
caught = 1;
siglongjmp(env,1);
}
typedef void (*__sighandler_t)();
void install_signal_handler(int signo, __sighandler_t handler) {
struct sigaction sa;
sa.sa_handler = (void *)handler;
sigemptyset(&sa.sa_mask);
// needed for the ucontext parameter to be available
sa.sa_flags = SA_SIGINFO;
sigaction(signo, &sa, NULL);
}
int main() {
double a, b;
b = 0.0;
asm volatile("mtfsfi 6,15");
// install the handler for SIGFPE
install_signal_handler(SIGFPE, signal_handler);
// trigger an exception
caught = 0;
if (!sigsetjmp(env,1)) {
a = b/b;
printf("Should never get here\n");
return 1;
}
else {
printf("Returning from longjmp 1, caught signal: %d\n",caught);
}
if (!caught)
return 1;
// trigger another exception
caught = 0;
if (!sigsetjmp(env,1)) {
a = b/b;
printf("Should never get here\n");
return 1;
}
else {
printf("Returning from longjmp 2, caught another signal: %d
\n",caught);
}
if (!caught)
return 1;
return 0;
}
The output is (on a dual G5):
$ gcc -o sig6 sig6.c
$ ./sig6
Returning from longjmp 1, caught signal: 1
Should never get here
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.5.5
BuildVersion: 9F33
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.
I admit I took the easy road until now and simply started off from a
copy of the FreeBSD exception handling code we already have. Maybe
I'll have to dig in Mach after all (until now I've been able to avoid
that :)
Thanks,
Jonas
_______________________________________________
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