• M
    error: On abort, report where the error was created · 1e9b65bb
    Markus Armbruster 提交于
    This is particularly useful when we abort in error_propagate(),
    because there the stack backtrace doesn't lead to where the error was
    created.  Looks like this:
    
        Unexpected error in parse_block_error_action() at .../qemu/blockdev.c:322:
        qemu-system-x86_64: -drive if=none,werror=foo: 'foo' invalid write error action
        Aborted (core dumped)
    
    Note: to get this example output, I monkey-patched drive_new() to pass
    &error_abort to blockdev_init().
    
    To keep the error handling boiler plate from growing even more, all
    error_setFOO() become macros expanding into error_setFOO_internal()
    with additional __FILE__, __LINE__, __func__ arguments.  Not exactly
    pretty, but it works.
    
    The macro trickery breaks down when you take the address of an
    error_setFOO().  Fortunately, we do that in just one place: qemu-ga's
    Windows VSS provider and requester DLL wants to call
    error_setg_win32() through a function pointer "to avoid linking glib
    to the DLL".  Use error_setg_win32_internal() there.  The use of the
    function pointer is already wrapped in a macro, so the churn isn't
    bad.
    
    Code size increases by some 35KiB for me (0.7%).  Tolerable.  Could be
    less if we passed relative rather than absolute source file names to
    the compiler, or forwent reporting __func__.
    Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
    Reviewed-by: NEric Blake <eblake@redhat.com>
    Acked-by: NLaszlo Ersek <lersek@redhat.com>
    1e9b65bb
error.c 4.2 KB