[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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.