[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <25dfde77-fdad-0b99-75ec-4ba480058970@rasmusvillemoes.dk>
Date: Mon, 6 May 2019 09:34:55 +0200
From: Rasmus Villemoes <linux@...musvillemoes.dk>
To: Ingo Molnar <mingo@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Jason Baron <jbaron@...mai.com>, linux-kernel@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org,
linux-arm-kernel@...ts.infradead.org, x86@...nel.org,
Michael Ellerman <mpe@...erman.id.au>,
Will Deacon <will.deacon@....com>,
Ingo Molnar <mingo@...hat.com>, Arnd Bergmann <arnd@...db.de>,
Nathan Chancellor <natechancellor@...il.com>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH 00/10] implement DYNAMIC_DEBUG_RELATIVE_POINTERS
On 06/05/2019 09.05, Ingo Molnar wrote:
>
>
> 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?
Not sure. The report was from a build on CentOS with gcc 4.8.5, so I
tried installing the gcc-4.8 package on my Ubuntu machine and could
reproduce. Then I tried installed gcc-4.9, and after disabling
CONFIG_RETPOLINE (both CentOS and Ubuntu carry backported retpoline
support in their 4.8, but apparently not 4.9), I could see that the
problem was gone. But whether it's gone because it no longer elides an
asm volatile() on a code path it otherwise emits code for, or because it
simply doesn't emit the unused static inline() at all I don't know.
I thought 0day also tested a range of supported compiler versions, so I
was rather surprised at getting this report at all. But I suppose the
arch/config matrix is already pretty huge. Anyway, the bug certainly
doesn't exist in any of the gcc versions 0day does test.
I _am_ bending the C rules a bit with the "extern some_var; asm
volatile(".section some_section\nsome_var: blabla");". I should probably
ask on the gcc list whether this way of defining a local symbol in
inline assembly and referring to it from C is supposed to work, or it
just happens to work by chance.
Rasmus
Powered by blists - more mailing lists