Le 19/08/2019 à 15:23, Segher Boessenkool a écrit :

On Mon, Aug 19, 2019 at 01:06:31PM +0000, Christophe Leroy wrote:

quoted

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