Re: objtool segfault with ORC unwinder enabled

[Markus]

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.)

BR,
Markus

Attachment: irq.o.xz
Description: application/xz