http://d.puremagic.com/issues/show_bug.cgi?id=5517
--- Comment #5 from Iain Buclaw <ibuc...@ubuntu.com> 2011-03-06 04:49:31 PST --- (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. :) > > > 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 > this stuff. 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 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
