Re: [PATCH 3/3] powerpc: use __builtin_trap() in BUG/WARN macros.

From: Christophe Leroy
Date: Mon Aug 19 2019 - 10:09:04 EST




Le 19/08/2019 Ã 15:23, Segher Boessenkool a ÃcritÂ:
On Mon, Aug 19, 2019 at 01:06:31PM +0000, Christophe Leroy wrote:
Note that we keep using an assembly text using "twi 31, 0, 0" for
inconditional traps because GCC drops all code after
__builtin_trap() when the condition is always true at build time.

As I said, it can also do this for conditional traps, if it can prove
the condition is always true.

But we have another branch for 'always true' and 'always false' using __builtin_constant_p(), which don't use __builtin_trap(). Is there anything wrong with that ?:

#define BUG_ON(x) do { \
if (__builtin_constant_p(x)) { \
if (x) \
BUG(); \
} else { \
if (x) \
__builtin_trap(); \
BUG_ENTRY("", 0); \
} \
} while (0)

#define WARN_ON(x) ({ \
int __ret_warn_on = !!(x); \
if (__builtin_constant_p(__ret_warn_on)) { \
if (__ret_warn_on) \
__WARN_TAINT(TAINT_WARN); \
} else { \
if (__ret_warn_on) \
__builtin_trap(); \
BUG_ENTRY("", BUGFLAG_WARNING | BUGFLAG_TAINT(TAINT_WARN)); \
} \
unlikely(__ret_warn_on); \
})



Can you put the bug table asm *before* the __builtin_trap maybe? That
should make it all work fine... If you somehow can tell what machine
instruction is that trap, anyway.

And how can I tell that ?

When I put it *after*, it always points to the trap instruction. When I put it *before* it usually points on the first instruction used to prepare the registers for the trap condition.

Christophe