Messages in this thread | | | Date | Sun, 07 Mar 2010 11:04:31 +0200 | From | Avi Kivity <> | Subject | Re: use of setjmp/longjmp in x86 emulator. |
| |
On 03/02/2010 10:49 AM, Gleb Natapov wrote: > On Mon, Mar 01, 2010 at 02:56:59PM -0800, H. Peter Anvin wrote: > >> On 03/01/2010 02:31 PM, H. Peter Anvin wrote: >> >>> On 03/01/2010 11:18 AM, Zachary Amsden wrote: >>> >>>> It's going to be ugly to emulate segmentation, NX and write protect >>>> support without hardware to do this checking for you, but it's just what >>>> you have to do in this slow path - tedious, fully specified emulation. >>>> >>>> Just because it's tedious doesn't mean we need to use setjmp / longjmp. >>>> Throw / catch might be effective, but it's still pretty bizarre to do >>>> tricks like that in C. >>>> >>>> >>> Well, setjmp/longjmp really is not much more than exception handling in C. >>> >>> >> For what it's worth, I think that setjmp/longjmp is not anywhere near as >> dangerous as people want to make it out to be. gcc will warn for >> dangerous uses (and a lot of non-dangerous uses), but generally the >> difficult problems can be dealt with by moving the setjmp-protected code >> into a separate function. >> >> > Can I consider this as ACK for something like the patch blow? :) (with > proper x86 version of setjmp/longjmp of course). >
The setjmp/longjmp implementation should definitely live in arch/*/lib, even if kvm is the only user.
-- error compiling committee.c: too many arguments to function
| |