From: Rasmus Villemoes
Date: Mon May 06 2019 - 02:48:57 EST

On 09/04/2019 23.25, Rasmus Villemoes wrote:

> While refreshing these patches, which were orignally just targeted at
> x86-64, it occured to me that despite the implementation relying on
> inline asm, there's nothing x86 specific about it, and indeed it seems
> to work out-of-the-box for ppc64 and arm64 as well, but those have
> only been compile-tested.

So, apart from the Clang build failures for non-x86, I now also got a
report that gcc 4.8 miscompiles this stuff in some cases [1], even for
x86 - gcc 4.9 does not seem to have the problem. So, given that the 5.2
merge window just opened, I suppose this is the point where I should
pull the plug on this experiment :(


[1] Specifically, the problem manifested in net/ipv4/tcp_input.c: Both
uses of the static inline inet_csk_clear_xmit_timer() pass a
compile-time constant 'what', so the ifs get folded away and both uses
are completely inlined. Yet, gcc still decides to emit a copy of the
final 'else' branch of inet_csk_clear_xmit_timer() as its own
inet_csk_reset_xmit_timer.part.55 function, which is of course unused.
And despite the asm() that defines the ddebug descriptor being an "asm
volatile", gcc thinks it's fine to elide that (the code path is
unreachable, after all....), so the entire asm for that function is

.section .text.unlikely
.type inet_csk_reset_xmit_timer.part.55, @function
movq $.LC1, %rsi #,
movq $__UNIQUE_ID_ddebug160, %rdi #,
xorl %eax, %eax #
jmp __dynamic_pr_debug #
.size inet_csk_reset_xmit_timer.part.55,

which of course fails to link since the symbol __UNIQUE_ID_ddebug160 is
nowhere defined.