http://d.puremagic.com/issues/show_bug.cgi?id=5517
--- Comment #6 from Don <clugd...@yahoo.com.au> 2011-03-06 07:49:39 PST ---
(In reply to comment #5)
> (In reply to comment #4)
> > (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'
> > interrupt.
> >
> >
> > > 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.
> >
>
> Well, signals are != exceptions. :)
Even if you have that opinion, HLT is not a segfault.
If Linux does the stupidity of treating privileged instruction violations as
segfaults (are you CERTAIN it does? It's really hard to believe), then we
shouldn't try to cover up that stupidity by pretend that SIGSEGV only ever
means a segfault. Does it really report a segfault on this code?
void main()
{
asm {
hlt;
}
}
> There are 2 alternatives I can think of instead of using 'hlt'
>
> 1) Throw an exception (goes against release mode).
>
> 2) Raise an alternate interrupt. Like 'hlt', these are single byte opcodes.
>
> - int 0x3; #BP will invoke SIGTRAP signal handler.
> - ud2; #UD will invoke SIGILL signal handler.
>
> Regards
The first one won't work -- it defeats the ENTIRE PURPOSE of the feature. The
second one's really, really wrong, and I can't see that it would even be an
improvement.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
