--- Comment #4 from Don <clugd...@yahoo.com.au> 2011-03-05 18:28:56 PST ---
(In reply to comment #3)
> (In reply to comment #2)
> > Some further detail: 0xF4, the HLT opcode, is a privileged instruction; it
> > doesn't actually get executed. Instead, a Privileged Instruction hardware
> > exception is raised. I would expect Linux to turn this into SIGILL. So I
> > would
> > expect an exit code of 132, if nothing is done to process it. There is no
> > way
> > it should give a SEGV.
> If I was going off what I recall, I would have said that when a program
> receives the hlt instruction; it just stops executing instructions until there
> is an interrupt (in other words it just floats off in an undefined space).
That's what it does in ring 0 (ie, inside the kernel). But outside the kernel,
it's a privileged instruction, which generates a hardware 'illegal instruction'
> But I've looked it up, and HLT invokes SIGSEGV signal afterall...
Wow. Then Linux is just wrong. It should definitely be SIGILL. There's no
memory access violation.
> > On Windows, druntime checks the offending instruction, and if it is HLT, it
> > is
> > identified as a runtime assert(0).
> So on Windows, the runtime has a bespoke signal handler?
Everything you'd call a signal on Linux, is just a system exception on Windows.
D's exception handling uses the exact same mechanism.
On all platforms, main is surrounded by a catch(...) which displays error
messages from any uncaught exceptions.
On Windows, this includes hardware faults as well as D-generated exceptions.
The impression I get from the little I know of Unix signal handling, it seems
to be one of the few things that Unix got horribly wrong. Windows structured
exception handling is brilliant (albeit almost completely undocumented!) I am
extremely impressed with it. For example, there's no restrictions on what you
can do inside an exception handler.
So there's probably more challenges for the *nix implementation of a lot of
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------