lkml.org 
[lkml]   [2018]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: objtool warnings on 4.14-stable/gcc-7.3.0
On Thu, Feb 15, 2018 at 04:01:57PM +0100, Arnd Bergmann wrote:
> On Wed, Feb 14, 2018 at 11:45 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> > On Wed, Feb 14, 2018 at 04:24:12PM -0600, Josh Poimboeuf wrote:
> >> On Wed, Feb 14, 2018 at 04:11:15PM +0100, Arnd Bergmann wrote:
> >> > Hi Josh,
> >> >
> >> > I recently did some randconfig testing with a plain 4.14-stable kernel
> >> > and gcc-7.3.0, and came across three distinct objtool warnings:
> >> >
> >> > drivers/misc/lkdtm_bugs.o: warning: objtool:
> >> > lkdtm_CORRUPT_LIST_ADD()+0x15: return with modified stack frame
> >
> > While this is probably an objtool bug, the code is very odd:
> >
> > 00000000000001a8 <lkdtm_CORRUPT_LIST_ADD>:
> > 1a8: e8 00 00 00 00 callq 1ad <lkdtm_CORRUPT_LIST_ADD+0x5>
> > 1a9: R_X86_64_PC32 __fentry__-0x4
> > 1ad: 55 push %rbp
> > 1ae: 48 89 e5 mov %rsp,%rbp
> > 1b1: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp
> > 1b5: 48 83 ec 20 sub $0x20,%rsp
> > 1b9: 48 89 ec mov %rbp,%rsp
> > 1bc: 5d pop %rbp
> > 1bd: c3 retq
> >
> > The function just allocates/aligns its stack space and then returns. It
> > seems like GCC was too smart for its own good here, as the function
> > doesn't test what it's supposed to.
>
> AFAIU, there is an optimization step in gcc that eliminates basic blocks
> that contain an unconditional NULL pointer dereference, based on the
> assumption that it's undefined behavior, and if we ever get here, it is
> free to drop not only code after but also before it as long as it doesn't
> have any side-effects.

Ok, I expected something like that. GCC "undefined behavior" strikes
again.

Kees, I suppose you'll need to obfuscate the code to stay one step ahead
of GCC.

While this may be an objtool bug, I might not fix it because it served a
useful purpose here in finding GCC crap.

> I would have expected an actual NULL pointer dereference to remain
> in the function though, or at least another trapping instruction.
>
> > Can you share the config for this one?
>
> https://pastebin.com/qFV6SPWP

Would be interesting to analyze that config to understand what options
are causing GCC to do that. I don't see this "optimization" with my
config.

--
Josh

\
 
 \ /
  Last update: 2018-02-15 19:28    [W:0.118 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site