* Rasmus Villemoes <li...@rasmusvillemoes.dk> wrote:
> 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 :( > > Rasmus > > [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 > inet_csk_reset_xmit_timer.part.55: > movq $.LC1, %rsi #, > movq $__UNIQUE_ID_ddebug160, %rdi #, > xorl %eax, %eax # > jmp __dynamic_pr_debug # > .size inet_csk_reset_xmit_timer.part.55, > .-inet_csk_reset_xmit_timer.part.55 > > which of course fails to link since the symbol __UNIQUE_ID_ddebug160 is > nowhere defined. It's sad to see such nice data footprint savings go the way of the dodo just because GCC 4.8 is buggy. The current compatibility cut-off is GCC 4.6: GNU C 4.6 gcc --version Do we know where the GCC bug was fixed, was it in GCC 4.9? According to the GCC release dates: https://www.gnu.org/software/gcc/releases.html 4.8.0 was released in early-2013, while 4.9.0 was released in early-2014. So the tooling compatibility window for latest upstream would narrow from ~6 years to ~5 years. Thanks, Ingo
