[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180103135924.ajpb5kslhkwtd5gb@treble>
Date: Wed, 3 Jan 2018 07:59:24 -0600
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Markus <M4rkusXXL@....de>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
lkml <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>
Subject: Re: objtool segfault with ORC unwinder enabled
On Wed, Jan 03, 2018 at 01:22:07PM +0100, Markus wrote:
> On Wed, Jan 03, 2018 at 12:19:41 CET Greg Kroah-Hartman wrote:
> > On Wed, Jan 03, 2018 at 11:49:08AM +0100, Markus wrote:
> > > Hello!
> > >
> > > ORC unwinder is enabled in stable for wider testing but still at least one
> > > bug is open:
> > > https://bugzilla.kernel.org/show_bug.cgi?id=197035
> >
> > Random web links on mailing lists don't help much, please put the
> > information here in the email.
>
> Its not a random web link. Its the official kernel.org bugtracker. But nobody
> seems to be looking at it.
>
> > > objtool will segfault because a NULL pointer is dereferenced.
> >
> > And how are you reproducing this?
>
> Just building the kernel with ORC enabled.
> (At least for me. Using framepointers compiles, enabling ORC again breaks it.)
> gcc 6.4.0 (In bug report others were tested as well.)
> elfutils 0.170
> What else may be interesting?
>
> > > Is a NULL pointer sym valid?
> > > If a NULL pointer is invalid, it has to be checked why it is sometimes
> > > NULL.
> > What .config is triggering this problem?
> See attachment.
>
> > And does this show up on 4.14.11, and 4.15-rc6?
> Both: yes.
>
> /tools/objtool/objtool orc generate --no-fp "arch/x86/kernel/irq.o"
>
> => segfault.
>
> Changing CFLAGS for objtool to O1 and starting from gdb:
>
> (gdb) r orc generate --no-fp "arch/x86/kernel/irq.o"
> Starting program: tools/objtool/objtool orc generate --no-fp "arch/x86/kernel/
> irq.o"
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x000055555555e06c in elf_rebuild_rela_section (sec=sec@...ry=0x7ffff690d010)
> at elf.c:554
> 554 relas[idx].r_info = GELF_R_INFO(rela->sym->idx, rela-
> >type);
> (gdb) bt
> #0 0x000055555555e06c in elf_rebuild_rela_section
> (sec=sec@...ry=0x7ffff690d010) at elf.c:554
> #1 0x000055555555d0aa in create_orc_sections (file=file@...ry=0x7ffffff7d740)
> at orc_gen.c:210
> #2 0x000055555555c146 in check (_objname=<optimized out>, _no_fp=<optimized
> out>, no_unreachable=<optimized out>, orc=orc@...ry=true) at check.c:1971
> #3 0x000055555555811f in cmd_orc (argc=<optimized out>, argv=0x7fffffffd8d8)
> at builtin-orc.c:54
> #4 0x000055555555f490 in handle_internal_command (argv=0x7fffffffd8d0,
> argc=4) at objtool.c:108
> #5 main (argc=4, argv=0x7fffffffd8d0) at objtool.c:131
> (gdb) p rela->sym
> $1 = (struct symbol *) 0x0
Hi Markus,
I'm unable to recreate. Can you attach one of the .o files (like the
above irq.o)?
--
Josh
Powered by blists - more mailing lists