[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 1/4] xen: introduce CONFIG_GENERIC_BUG_FRAME
- To: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Thu, 23 Feb 2023 14:32:00 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=J1bwNcqd/wS9i9LdTX7YyH1XYvzPUY/cKQ/CucThg90=; b=kKj1oayeokwSpefzQ1xazrrDZFcJhTKHHdIEFK4T7wI+Ft6MA5yvAmF9NL7t8rfqAAP3c65d8TcfV6eQdgsnQcikiou5z5+MLavgpJRKMeMTRpfTmOTllE1AnCCebyhdIfuykGU4ap2oZM0fj/D9Lq0VuGozOPCxrmp+KzuiPzjnJ4mSAo759h9QeJRzZhY4S1FqJsPNdpWzbjWgSJvjvu+nx0XPEvfkLx4TW75nezkUgDADmYClgLN669e47w113Ih9VrsS97Gd2B2VjYjcHIsKnncuTvHEgfu2szpapP0d2b1HJBnC1PKreRYLKrZUkjh+psgxva20dizhiiiFhQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gMdhxjzd1sddA966z8yLFV5JRxi4ulxbS7iT7rFI6/g19CF2RjpwDRxZeE0uSBQbk+u+UrR4s+UAZVw0LNFdOTBawPTU4JWs+f2NKYqh8wuS4iCU4LY2qDwhZ26EVCpubRTziY0VYTjtGapUiMu6E9CSHEBzE7TPNbVDo0macFBV2C3UUA13Op2LsCzyxmLGQIcAHRYtQfeDd/7bJI+LsRTki6/ud+XG7MBQxVQ+zsyaVJuICpj+/+Xvzv/6aEmBjE/Lcd9LchNLaLoIaloITS1LyAZe73DSpC31496QnWbXyxdwOjOr4bf7vTc4RH+xR8425oL+pLQFmkG0ZLhWQg==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Gianluca Guida <gianluca@xxxxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Thu, 23 Feb 2023 13:32:23 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 20.02.2023 17:40, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/xen/bug.h
> @@ -0,0 +1,161 @@
> +#ifndef __XEN_BUG_H__
> +#define __XEN_BUG_H__
> +
> +#define BUG_DISP_WIDTH 24
> +#define BUG_LINE_LO_WIDTH (31 - BUG_DISP_WIDTH)
> +#define BUG_LINE_HI_WIDTH (31 - BUG_DISP_WIDTH)
> +
> +#define BUGFRAME_run_fn 0
> +#define BUGFRAME_warn 1
> +#define BUGFRAME_bug 2
> +#define BUGFRAME_assert 3
> +
> +#define BUGFRAME_NR 4
> +
> +#ifndef __ASSEMBLY__
> +
> +#include <xen/errno.h>
> +#include <xen/lib.h>
> +#include <xen/stringify.h>
> +#include <xen/types.h>
> +
> +#include <asm/bug.h>
Looking at patch 2 onwards I came to wonder: How does that work without
you first removing stuff from the respective asm/bug.h (or adding
suitable #define-s to limit what gets defined below)? From all I can
tell the compiler should object to ...
> +#ifndef BUG_FRAME_STRUCT
> +
> +struct bug_frame {
> + signed int loc_disp:BUG_DISP_WIDTH;
> + unsigned int line_hi:BUG_LINE_HI_WIDTH;
> + signed int ptr_disp:BUG_DISP_WIDTH;
> + unsigned int line_lo:BUG_LINE_LO_WIDTH;
> + signed int msg_disp[];
> +};
... this, as asm/bug.h will have declared such a struct already. The
#define-s further down may not be a problem if what they expand to
matches in both places, but that's then still a latent trap to fall
into.
Jan
|
