[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v9 4/5] xen/arm: switch ARM to use generic implementation of bug.h
Hi,
On 04/04/2023 09:09, Oleksii wrote:
On Tue, 2023-04-04 at 08:41 +0200, Jan Beulich wrote:
On 03.04.2023 20:40, Oleksii wrote:
Hello Julien,
On Fri, 2023-03-31 at 22:05 +0100, Julien Grall wrote:
Hi Oleksii,
I was going to ack the patch but then I spotted something that
would
want some clarification.
On 29/03/2023 11:50, Oleksii Kurochko wrote:
diff --git a/xen/arch/arm/include/asm/bug.h
b/xen/arch/arm/include/asm/bug.h
index cacaf014ab..3fb0471a9b 100644
--- a/xen/arch/arm/include/asm/bug.h
+++ b/xen/arch/arm/include/asm/bug.h
@@ -1,6 +1,24 @@
#ifndef __ARM_BUG_H__
#define __ARM_BUG_H__
+/*
+ * Please do not include in the header any header that might
+ * use BUG/ASSERT/etc maros asthey will be defined later after
+ * the return to <xen/bug.h> from the current header:
+ *
+ * <xen/bug.h>:
+ * ...
+ * <asm/bug.h>:
+ * ...
+ * <any_header_which_uses_BUG/ASSERT/etc macros.h>
+ * ...
+ * ...
+ * #define BUG() ...
+ * ...
+ * #define ASSERT() ...
+ * ...
+ */
+
#include <xen/types.h>
#if defined(CONFIG_ARM_32)
@@ -11,76 +29,7 @@
# error "unknown ARM variant"
#endif
-#define BUG_FRAME_STRUCT
-
-struct bug_frame {
- signed int loc_disp; /* Relative address to the bug
address
*/
- signed int file_disp; /* Relative address to the
filename */
- signed int msg_disp; /* Relative address to the
predicate
(for ASSERT) */
- uint16_t line; /* Line number */
- uint32_t pad0:16; /* Padding for 8-bytes align */
-};
-
-#define bug_loc(b) ((const void *)(b) + (b)->loc_disp)
-#define bug_file(b) ((const void *)(b) + (b)->file_disp);
-#define bug_line(b) ((b)->line)
-#define bug_msg(b) ((const char *)(b) + (b)->msg_disp)
-
-/* Many versions of GCC doesn't support the asm %c parameter
which
would
- * be preferable to this unpleasantness. We use mergeable
string
- * sections to avoid multiple copies of the string appearing
in
the
- * Xen image. BUGFRAME_run_fn needs to be handled separately.
- */
Given this comment ...
-#define BUG_FRAME(type, line, file, has_msg, msg) do
{ \
- BUILD_BUG_ON((line) >>
16); \
- BUILD_BUG_ON((type) >=
BUGFRAME_NR); \
- asm
("1:"BUG_INSTR"\n"
\
- ".pushsection .rodata.str, \"aMS\", %progbits,
1\n" \
- "2:\t.asciz " __stringify(file)
"\n" \
-
"3:\n"
\
- ".if " #has_msg
"\n" \
- "\t.asciz " #msg
"\n" \
-
".endif\n"
\
-
".popsection\n"
\
- ".pushsection .bug_frames." __stringify(type) ",
\"a\",
%progbits\n"\
-
"4:\n"
\
- ".p2align
2\n" \
- ".long (1b -
4b)\n" \
- ".long (2b -
4b)\n" \
- ".long (3b -
4b)\n" \
- ".hword " __stringify(line) ",
0\n" \
-
".popsection");
\
-} while (0)
-
-/*
- * GCC will not allow to use "i" when PIE is enabled (Xen
doesn't
set the
- * flag but instead rely on the default value from the
compiler).
So the
- * easiest way to implement run_in_exception_handler() is to
pass
the to
- * be called function in a fixed register.
- */
-#define run_in_exception_handler(fn) do
{ \
- asm ("mov " __stringify(BUG_FN_REG) ",
%0\n" \
-
"1:"BUG_INSTR"\n"
\
- ".pushsection .bug_frames."
__stringify(BUGFRAME_run_fn)
"," \
- " \"a\",
%%progbits\n" \
-
"2:\n"
\
- ".p2align
2\n" \
- ".long (1b -
2b)\n" \
- ".long 0, 0,
0\n" \
- ".popsection" :: "r" (fn) : __stringify(BUG_FN_REG)
); \
-} while (0)
-
-#define WARN() BUG_FRAME(BUGFRAME_warn, __LINE__, __FILE__, 0,
"")
-
-#define BUG() do
{ \
- BUG_FRAME(BUGFRAME_bug, __LINE__, __FILE__, 0,
""); \
-
unreachable(); \
-} while (0)
-
-#define assert_failed(msg) do
{ \
- BUG_FRAME(BUGFRAME_assert, __LINE__, __FILE__, 1,
msg); \
-
unreachable(); \
-} while (0)
+#define BUG_ASM_CONST "c"
... you should explain in the commit message why this is needed
and
the
problem described above is not a problem anymore.
For instance, I managed to build it without 'c' on arm64 [1]. But
it
does break on arm32 [2]. I know that Arm is also where '%c' was
an
issue.
Skimming through linux, the reason seems to be that GCC may add
'#'
when
it should not. That said, I haven't look at the impact on the
generic
implementation. Neither I looked at which version may be affected
(the
original message was from 2011).
You are right that some compilers add '#' when it shouldn't. The
same
thing happens with RISC-V.
I am a bit confused with this answer. My point was that on at least on
Arm 32-bit we need to use 'c' otherwise it breaks.
AFAIU, this is not the same problem on RISC-V...
RISC-V doesn't know of a '#' prefix, does it? '#' is a comment
character
there afaik, like for many other architectures.
It doesn't and for RISC-V it's a comment character.
afaik '%c' is needed to skip prefix('sign' ) (# or $ ( in case of
x86)).
I mean that RISC-V doesn't put anything before immediate so there is no
need to use %c as we don't need to skip prefix/'sign' before immediate
but if start to use '%c' it will cause an compiler issue.
... because here you say it will break when using 'c'. Did I miss anything?
Anyway, it sounds like to me that the default definition in xen/bug.h
should be using 'c' rather than been empty because this seems to be the
more common approach.
To reduce the amount of patch to resend, I was actually thinking to
merge patch #1-3 and #5 (so leave this patch alone) and modify the
default in a follow-up. Any thoughts?
Cheers,
--
Julien Grall
|