[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dbafc03a-6eda-d9a3-c451-d242f03b01d9@c-s.fr>
Date: Mon, 19 Aug 2019 16:08:43 +0200
From: Christophe Leroy <christophe.leroy@....fr>
To: Segher Boessenkool <segher@...nel.crashing.org>
Cc: Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Michael Ellerman <mpe@...erman.id.au>,
linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH 3/3] powerpc: use __builtin_trap() in BUG/WARN macros.
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
Powered by blists - more mailing lists