Re: objtool segfault with ORC unwinder enabled

[Josh Poimboeuf]

On Wed, Jan 03, 2018 at 03:14:55PM +0100, Markus wrote:
> On Wed, Jan 03, 2018 at 14:59:24 CET Josh Poimboeuf wrote:
> > 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@entry=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@entry=0x7ffff690d010) at elf.c:554
> > > #1  0x000055555555d0aa in create_orc_sections
> > > (file=file@entry=0x7ffffff7d740) at orc_gen.c:210
> > > #2  0x000055555555c146 in check (_objname=<optimized out>,
> > > _no_fp=<optimized out>, no_unreachable=<optimized out>,
> > > orc=orc@entry=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
> > 
> 
> > I'm unable to recreate.  Can you attach one of the .o files (like the
> > above irq.o)?
> Sure, see attached. (From vanilla linux-4.14.11.)

There's something weird with the toolchain.  The object file doesn't
have an ELF section symbol for the .irqentry.text section.

Are there any special KCFLAGS being added?  Can you build the object
with V=1 to show the full gcc command line?

-- 
Josh