Re: [Xen-devel] [PATCH 1/3] xen/x86: Infrastructure to create BUG_FRAMES in asm code

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.04.15 at 22:06, <andrew.cooper3@xxxxxxxxxx> wrote:
> @@ -66,4 +68,40 @@ struct bug_frame {
>                                __stop_bug_frames_2[],
>                                __stop_bug_frames_3[];
>  
> +#else  /* !__ASSEMBLY__ */
> +
> +/*
> + * Construct a bugframe, suitable for using in assembly code.  Should always
> + * match the C version above.  One complication is having to stash the 
> strings
> + * in .rodata (TODO - figure out how to get GAS to elide duplicate 
> file_str's)

Use the 'M' and 'S' section flags (and perhaps the section name gcc
also uses for this purpose, .rodata.str1 or some such).

> +.macro BUG_FRAME type, line, file_str, second_frame, msg

Can we please avoid spreading the bad habit of starting directives
in the first column? The only thing formally allowed to start there is
a label.

> +92: ud2a

Instead of using number labels that can conflict with the context
the macro is used in, please use .L prefixed ones together with
\@ to reference the macro invocation count (as a unique number).

> +.if \second_frame
> +     .pushsection .rodata
> +     95: .asciz "\msg"
> +     .popsection
> +.long 0, (95b - 93b)
> +.endif
> +.popsection
> +.endm

Please be consistent with indentation.

> +#define WARN() BUG_FRAME BUGFRAME_warn, __LINE__, __FILE__, 0, 0
> +#define BUG()  BUG_FRAME BUGFRAME_bug,  __LINE__, __FILE__, 0, 0

I don't think the parentheses are particularly well suited for
assembly code.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel