Re: [Qemu-devel] [RFC] Introduce qemu_abort?

[Markus Armbruster]

Peter Maydell <address@hidden> writes:

> On 26 October 2011 19:34, Stefan Weil <address@hidden> wrote:
>> Adding the infrastructure (macros / implementation) could be done
>> faster. I suggest these interfaces in qemu-common.h:
>>
>> qemu_abort() - abort QEMU with a message containing function name,
>> file name and line (macro, see message text in my previous mail cited above)
>>
>> qemu_fatal(formatstring, ...) - abort QEMU with a printf like message
>> (function, prints "QEMU aborted, " and the text according to the parameters)
>
> We already have a couple of "print a message and abort" functions:
>   hw_error()  (prints "qemu: hardware error" message, dumps cpu state
>                for all cores and abort()s)
>   cpu_abort() (prints "qemu: fatal:" message, dumps cpu state for one
>                core and abort()s)
>   tcg_abort() (takes no arguments, acts like your proposed qemu_abort())
>
> ...perhaps we should try to straighten out the naming inconsistencies
> here and document which ones to use when.

Yes, that would be useful.

> I think the qemu_fatal() might be better addressed as part of a set
> of functions for handling fatal and other errors in a more consistent
> way. At the moment it's a bit random whether a device model will
> abort, warn but continue or silently continue if a guest does something
> that tickles unimplemented behaviour or does something that's probably
> a guest error (eg accessing nonexistent registers). It would be good
> to have some of this be user configurable (some people want to see
> "my guest OS is doing something that's probably a guest OS bug" warnings,
> some don't, for instance).

Yes.

assert() and abort() are strictly for programming errors: the programmer
screwed up, program is in disorder, and can't continue.  They're not
appropriate ways to handle environmental conditions that can be expected
(out of memory, network kaputt, ...), or bad input.  For QEMU, input
includes guest actions.

I generally don't bother to provide "nice" ways to abort on programming
error.  assert() is standard, and it's just fine.  To do anything about
it, I'll need a debugger anyway.  If you don't like abort() not telling
you function and line, use assert().

That said, if you want to wrap around yet another standard function, go
right ahead, one more won't make a difference.

> Regarding whether to put this into qemu 1.0 or not -- my preference
> would be for 'not' because any change touching a lot of files has
> the potential to cause pending patches/pullreqs people are trying
> to get in before the feature freeze deadline to no longer apply.

Agree.