* objtool segfault with ORC unwinder enabled @ 2018-01-03 10:49 Markus 2018-01-03 11:19 ` Greg Kroah-Hartman 0 siblings, 1 reply; 22+ messages in thread From: Markus @ 2018-01-03 10:49 UTC (permalink / raw) To: lkml; +Cc: Josh Poimboeuf, Greg Kroah-Hartman, Ingo Molnar 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 objtool will segfault because a NULL pointer is dereferenced. Is a NULL pointer sym valid? If a NULL pointer is invalid, it has to be checked why it is sometimes NULL. Thank you! Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: objtool segfault with ORC unwinder enabled 2018-01-03 10:49 objtool segfault with ORC unwinder enabled Markus @ 2018-01-03 11:19 ` Greg Kroah-Hartman 2018-01-03 12:22 ` Markus 0 siblings, 1 reply; 22+ messages in thread From: Greg Kroah-Hartman @ 2018-01-03 11:19 UTC (permalink / raw) To: Markus; +Cc: lkml, Josh Poimboeuf, Ingo Molnar 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. > objtool will segfault because a NULL pointer is dereferenced. And how are you reproducing this? > 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? And does this show up on 4.14.11, and 4.15-rc6? thanks, greg k-h ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: objtool segfault with ORC unwinder enabled 2018-01-03 11:19 ` Greg Kroah-Hartman @ 2018-01-03 12:22 ` Markus 2018-01-03 13:59 ` Josh Poimboeuf 2018-01-03 14:14 ` Greg Kroah-Hartman 0 siblings, 2 replies; 22+ messages in thread From: Markus @ 2018-01-03 12:22 UTC (permalink / raw) To: Greg Kroah-Hartman; +Cc: lkml, Josh Poimboeuf, Ingo Molnar [-- Attachment #1: Type: text/plain, Size: 2243 bytes --] 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 BR, Markus [-- Attachment #2: config.xz --] [-- Type: application/x-xz, Size: 8428 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: objtool segfault with ORC unwinder enabled 2018-01-03 12:22 ` Markus @ 2018-01-03 13:59 ` Josh Poimboeuf 2018-01-03 14:14 ` Markus 2018-01-03 14:14 ` Greg Kroah-Hartman 1 sibling, 1 reply; 22+ messages in thread From: Josh Poimboeuf @ 2018-01-03 13:59 UTC (permalink / raw) To: Markus; +Cc: Greg Kroah-Hartman, lkml, Ingo Molnar 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 Hi Markus, I'm unable to recreate. Can you attach one of the .o files (like the above irq.o)? -- Josh ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: objtool segfault with ORC unwinder enabled 2018-01-03 13:59 ` Josh Poimboeuf @ 2018-01-03 14:14 ` Markus 2018-01-03 16:36 ` Josh Poimboeuf 0 siblings, 1 reply; 22+ messages in thread From: Markus @ 2018-01-03 14:14 UTC (permalink / raw) To: Josh Poimboeuf; +Cc: Greg Kroah-Hartman, lkml, Ingo Molnar [-- Attachment #1: Type: text/plain, Size: 2779 bytes --] 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 #2: irq.o.xz --] [-- Type: application/x-xz, Size: 3388 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: objtool segfault with ORC unwinder enabled 2018-01-03 14:14 ` Markus @ 2018-01-03 16:36 ` Josh Poimboeuf 2018-01-03 17:26 ` Markus 0 siblings, 1 reply; 22+ messages in thread From: Josh Poimboeuf @ 2018-01-03 16:36 UTC (permalink / raw) To: Markus; +Cc: Greg Kroah-Hartman, lkml, Ingo Molnar 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: objtool segfault with ORC unwinder enabled 2018-01-03 16:36 ` Josh Poimboeuf @ 2018-01-03 17:26 ` Markus 2018-01-04 15:46 ` Josh Poimboeuf 0 siblings, 1 reply; 22+ messages in thread From: Markus @ 2018-01-03 17:26 UTC (permalink / raw) To: Josh Poimboeuf; +Cc: Greg Kroah-Hartman, lkml, Ingo Molnar On Wed, Jan 03, 2018 at 17:36:30 CET Josh Poimboeuf wrote: > 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: > > > > /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? I have not added anything. There is no env variable set like $KCFLAGS or $CFLAGS. (If that was the question.) I think you mean this line from output: gcc -Wp,-MD,arch/x86/kernel/.irq.o.d -nostdinc -isystem /usr/lib/gcc/x86_64- pc-linux-gnu/6.4.0/include -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./ include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h - D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict- aliasing -fno-common -fshort-wchar -Werror-implicit-function-declaration -Wno- format-security -std=gnu89 -fno-PIE -mno-sse -mno-mmx -mno-sse2 -mno-3dnow - mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 - mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone - mcmodel=kernel -funit-at-a-time -DCONFIG_AS_CFI=1 - DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 - DCONFIG_AS_AVX512=1 -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe -Wno- sign-compare -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks - Wno-frame-address -O2 --param=allow-store-data-races=0 -DCC_HAVE_ASM_GOTO - Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable - Wno-unused-const-variable -fomit-frame-pointer -fno-var-tracking-assignments - Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fno- stack-check -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes - Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init - Iarch/x86/kernel/../include/asm/trace -DKBUILD_BASENAME='"irq"' - DKBUILD_MODNAME='"irq"' -c -o arch/x86/kernel/.tmp_irq.o arch/x86/kernel/irq.c The next line is the objtool that segfaults. BR, Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: objtool segfault with ORC unwinder enabled 2018-01-03 17:26 ` Markus @ 2018-01-04 15:46 ` Josh Poimboeuf 2018-01-04 16:56 ` Markus 0 siblings, 1 reply; 22+ messages in thread From: Josh Poimboeuf @ 2018-01-04 15:46 UTC (permalink / raw) To: Markus; +Cc: Greg Kroah-Hartman, lkml, Ingo Molnar On Wed, Jan 03, 2018 at 06:26:19PM +0100, Markus wrote: > > > > 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? > > I have not added anything. There is no env variable set like $KCFLAGS or > $CFLAGS. (If that was the question.) > > I think you mean this line from output: > gcc -Wp,-MD,arch/x86/kernel/.irq.o.d -nostdinc -isystem /usr/lib/gcc/x86_64- > pc-linux-gnu/6.4.0/include -I./arch/x86/include -I./arch/x86/include/generated > -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./ > include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h - > D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict- > aliasing -fno-common -fshort-wchar -Werror-implicit-function-declaration -Wno- > format-security -std=gnu89 -fno-PIE -mno-sse -mno-mmx -mno-sse2 -mno-3dnow - > mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 - > mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone - > mcmodel=kernel -funit-at-a-time -DCONFIG_AS_CFI=1 - > DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 > -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 - > DCONFIG_AS_AVX512=1 -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe -Wno- > sign-compare -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks - > Wno-frame-address -O2 --param=allow-store-data-races=0 -DCC_HAVE_ASM_GOTO - > Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable - > Wno-unused-const-variable -fomit-frame-pointer -fno-var-tracking-assignments - > Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fno- > stack-check -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes - > Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init - > Iarch/x86/kernel/../include/asm/trace -DKBUILD_BASENAME='"irq"' - > DKBUILD_MODNAME='"irq"' -c -o arch/x86/kernel/.tmp_irq.o arch/x86/kernel/irq.c > > The next line is the objtool that segfaults. I don't see anything unusual there. Are there any Gentoo patches against either the kernel or GCC which would strip unused symbols? -- Josh ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: objtool segfault with ORC unwinder enabled 2018-01-04 15:46 ` Josh Poimboeuf @ 2018-01-04 16:56 ` Markus 2018-01-04 17:32 ` Josh Poimboeuf 0 siblings, 1 reply; 22+ messages in thread From: Markus @ 2018-01-04 16:56 UTC (permalink / raw) To: Josh Poimboeuf; +Cc: Greg Kroah-Hartman, lkml, Ingo Molnar On Thursday, 4 January 2018 16:46:13 CET Josh Poimboeuf wrote: > On Wed, Jan 03, 2018 at 06:26:19PM +0100, Markus wrote: > > > > > 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? > > > > I have not added anything. There is no env variable set like $KCFLAGS or > > $CFLAGS. (If that was the question.) > > > > I think you mean this line from output: > > gcc -Wp,-MD,arch/x86/kernel/.irq.o.d -nostdinc -isystem > > /usr/lib/gcc/x86_64- pc-linux-gnu/6.4.0/include -I./arch/x86/include > > -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi > > -I./arch/x86/include/generated/uapi -I./ include/uapi > > -I./include/generated/uapi -include ./include/linux/kconfig.h - > > D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict- > > aliasing -fno-common -fshort-wchar -Werror-implicit-function-declaration > > -Wno- format-security -std=gnu89 -fno-PIE -mno-sse -mno-mmx -mno-sse2 > > -mno-3dnow - mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 > > -mno-fp-ret-in-387 - mpreferred-stack-boundary=3 -mskip-rax-setup > > -mtune=generic -mno-red-zone - mcmodel=kernel -funit-at-a-time > > -DCONFIG_AS_CFI=1 - > > DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 > > -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1 > > -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 - DCONFIG_AS_AVX512=1 > > -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe -Wno- sign-compare > > -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks - > > Wno-frame-address -O2 --param=allow-store-data-races=0 -DCC_HAVE_ASM_GOTO > > - Wframe-larger-than=2048 -fno-stack-protector > > -Wno-unused-but-set-variable - Wno-unused-const-variable > > -fomit-frame-pointer -fno-var-tracking-assignments - > > Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fno- > > stack-check -fconserve-stack -Werror=implicit-int > > -Werror=strict-prototypes - Werror=date-time > > -Werror=incompatible-pointer-types -Werror=designated-init - > > Iarch/x86/kernel/../include/asm/trace -DKBUILD_BASENAME='"irq"' - > > DKBUILD_MODNAME='"irq"' -c -o arch/x86/kernel/.tmp_irq.o > > arch/x86/kernel/irq.c > > > > The next line is the objtool that segfaults. > > I don't see anything unusual there. Are there any Gentoo patches > against either the kernel or GCC which would strip unused symbols? The kernel is the vanilla kernel. (4.14.11 and also 4.15-rc6) Its not a gentoo specific gcc patch. (Then every gentoo user would be affected?) But I enabled ld.gold as default linker like 5 years ago. Never had a problem with this. Is ld.gold supposed to fail here? I switched back to ld.bfd and it seems to work. BR, Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: objtool segfault with ORC unwinder enabled 2018-01-04 16:56 ` Markus @ 2018-01-04 17:32 ` Josh Poimboeuf 2018-01-04 18:25 ` Markus 0 siblings, 1 reply; 22+ messages in thread From: Josh Poimboeuf @ 2018-01-04 17:32 UTC (permalink / raw) To: Markus; +Cc: Greg Kroah-Hartman, lkml, Ingo Molnar On Thu, Jan 04, 2018 at 05:56:30PM +0100, Markus wrote: > On Thursday, 4 January 2018 16:46:13 CET Josh Poimboeuf wrote: > > On Wed, Jan 03, 2018 at 06:26:19PM +0100, Markus wrote: > > > > > > 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? > > > > > > I have not added anything. There is no env variable set like $KCFLAGS or > > > $CFLAGS. (If that was the question.) > > > > > > I think you mean this line from output: > > > gcc -Wp,-MD,arch/x86/kernel/.irq.o.d -nostdinc -isystem > > > /usr/lib/gcc/x86_64- pc-linux-gnu/6.4.0/include -I./arch/x86/include > > > -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi > > > -I./arch/x86/include/generated/uapi -I./ include/uapi > > > -I./include/generated/uapi -include ./include/linux/kconfig.h - > > > D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict- > > > aliasing -fno-common -fshort-wchar -Werror-implicit-function-declaration > > > -Wno- format-security -std=gnu89 -fno-PIE -mno-sse -mno-mmx -mno-sse2 > > > -mno-3dnow - mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 > > > -mno-fp-ret-in-387 - mpreferred-stack-boundary=3 -mskip-rax-setup > > > -mtune=generic -mno-red-zone - mcmodel=kernel -funit-at-a-time > > > -DCONFIG_AS_CFI=1 - > > > DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 > > > -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1 > > > -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 - DCONFIG_AS_AVX512=1 > > > -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe -Wno- sign-compare > > > -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks - > > > Wno-frame-address -O2 --param=allow-store-data-races=0 -DCC_HAVE_ASM_GOTO > > > - Wframe-larger-than=2048 -fno-stack-protector > > > -Wno-unused-but-set-variable - Wno-unused-const-variable > > > -fomit-frame-pointer -fno-var-tracking-assignments - > > > Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fno- > > > stack-check -fconserve-stack -Werror=implicit-int > > > -Werror=strict-prototypes - Werror=date-time > > > -Werror=incompatible-pointer-types -Werror=designated-init - > > > Iarch/x86/kernel/../include/asm/trace -DKBUILD_BASENAME='"irq"' - > > > DKBUILD_MODNAME='"irq"' -c -o arch/x86/kernel/.tmp_irq.o > > > arch/x86/kernel/irq.c > > > > > > The next line is the objtool that segfaults. > > > > I don't see anything unusual there. Are there any Gentoo patches > > against either the kernel or GCC which would strip unused symbols? > > The kernel is the vanilla kernel. (4.14.11 and also 4.15-rc6) > Its not a gentoo specific gcc patch. (Then every gentoo user would be > affected?) > > But I enabled ld.gold as default linker like 5 years ago. Never had a problem > with this. > > Is ld.gold supposed to fail here? > > I switched back to ld.bfd and it seems to work. Ah, that explains it. With CONFIG_MODVERSIONS, the linker does some work after gcc, but before objtool. Can you try this patch? (Note this isn't the final patch, as this breaks the CONFIG_MODVERSIONS=n case.) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index cb8997ed0149..3cf3cc6077ea 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -270,7 +270,7 @@ endif # 'OBJECT_FILES_NON_STANDARD_foo.o := 'n': override directory skip for a file cmd_objtool = $(if $(patsubst y%,, \ $(OBJECT_FILES_NON_STANDARD_$(basetarget).o)$(OBJECT_FILES_NON_STANDARD)n), \ - $(__objtool_obj) $(objtool_args) "$(@)";) + $(__objtool_obj) $(objtool_args) "$(@D)/.tmp_$(@F)";) objtool_obj = $(if $(patsubst y%,, \ $(OBJECT_FILES_NON_STANDARD_$(basetarget).o)$(OBJECT_FILES_NON_STANDARD)n), \ $(__objtool_obj)) @@ -286,16 +286,16 @@ objtool_dep = $(objtool_obj) \ define rule_cc_o_c $(call echo-cmd,checksrc) $(cmd_checksrc) \ $(call cmd_and_fixdep,cc_o_c) \ + $(call echo-cmd,objtool) $(cmd_objtool) \ $(cmd_modversions_c) \ $(cmd_checkdoc) \ - $(call echo-cmd,objtool) $(cmd_objtool) \ $(call echo-cmd,record_mcount) $(cmd_record_mcount) endef define rule_as_o_S $(call cmd_and_fixdep,as_o_S) \ - $(cmd_modversions_S) \ - $(call echo-cmd,objtool) $(cmd_objtool) + $(call echo-cmd,objtool) $(cmd_objtool) \ + $(cmd_modversions_S) endef # List module undefined symbols (or empty line if not enabled) ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: objtool segfault with ORC unwinder enabled 2018-01-04 17:32 ` Josh Poimboeuf @ 2018-01-04 18:25 ` Markus 2018-01-10 17:14 ` Markus 0 siblings, 1 reply; 22+ messages in thread From: Markus @ 2018-01-04 18:25 UTC (permalink / raw) To: Josh Poimboeuf; +Cc: Greg Kroah-Hartman, lkml, Ingo Molnar On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote: > On Thu, Jan 04, 2018 at 05:56:30PM +0100, Markus wrote: > > On Thursday, 4 January 2018 16:46:13 CET Josh Poimboeuf wrote: > > > I don't see anything unusual there. Are there any Gentoo patches > > > against either the kernel or GCC which would strip unused symbols? > > > > The kernel is the vanilla kernel. (4.14.11 and also 4.15-rc6) > > Its not a gentoo specific gcc patch. (Then every gentoo user would be > > affected?) > > > > But I enabled ld.gold as default linker like 5 years ago. Never had a > > problem with this. > > > > Is ld.gold supposed to fail here? > > > > I switched back to ld.bfd and it seems to work. > > Ah, that explains it. With CONFIG_MODVERSIONS, the linker does some > work after gcc, but before objtool. Can you try this patch? (Note this > isn't the final patch, as this breaks the CONFIG_MODVERSIONS=n case.) > > diff --git a/scripts/Makefile.build b/scripts/Makefile.build > index cb8997ed0149..3cf3cc6077ea 100644 > --- a/scripts/Makefile.build > +++ b/scripts/Makefile.build > @@ -270,7 +270,7 @@ endif > # 'OBJECT_FILES_NON_STANDARD_foo.o := 'n': override directory skip for a > file cmd_objtool = $(if $(patsubst y%,, \ > $(OBJECT_FILES_NON_STANDARD_$(basetarget).o)$ (OBJECT_FILES_NON_STANDARD)n) > , \ - $(__objtool_obj) $(objtool_args) "$(@)";) > + $(__objtool_obj) $(objtool_args) "$(@D)/.tmp_$(@F)";) > objtool_obj = $(if $(patsubst y%,, \ > $(OBJECT_FILES_NON_STANDARD_$(basetarget).o)$ (OBJECT_FILES_NON_STANDARD)n) > , \ $(__objtool_obj)) > @@ -286,16 +286,16 @@ objtool_dep = $(objtool_obj) \ > define rule_cc_o_c > $(call echo-cmd,checksrc) $(cmd_checksrc) \ > $(call cmd_and_fixdep,cc_o_c) \ > + $(call echo-cmd,objtool) $(cmd_objtool) \ > $(cmd_modversions_c) \ > $(cmd_checkdoc) \ > - $(call echo-cmd,objtool) $(cmd_objtool) \ > $(call echo-cmd,record_mcount) $(cmd_record_mcount) > endef > > define rule_as_o_S > $(call cmd_and_fixdep,as_o_S) \ > - $(cmd_modversions_S) \ > - $(call echo-cmd,objtool) $(cmd_objtool) > + $(call echo-cmd,objtool) $(cmd_objtool) \ > + $(cmd_modversions_S) > endef > > # List module undefined symbols (or empty line if not enabled) With that patch the kernel is building with ld.gold. BR, Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: objtool segfault with ORC unwinder enabled 2018-01-04 18:25 ` Markus @ 2018-01-10 17:14 ` Markus 2018-01-11 4:13 ` Josh Poimboeuf 0 siblings, 1 reply; 22+ messages in thread From: Markus @ 2018-01-10 17:14 UTC (permalink / raw) To: Josh Poimboeuf; +Cc: Greg Kroah-Hartman, lkml, Ingo Molnar On Thursday, 4 January 2018 19:25:12 CET Markus wrote: > On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote: > > On Thu, Jan 04, 2018 at 05:56:30PM +0100, Markus wrote: > > > On Thursday, 4 January 2018 16:46:13 CET Josh Poimboeuf wrote: > > > > I don't see anything unusual there. Are there any Gentoo patches > > > > against either the kernel or GCC which would strip unused symbols? > > > > > > The kernel is the vanilla kernel. (4.14.11 and also 4.15-rc6) > > > Its not a gentoo specific gcc patch. (Then every gentoo user would be > > > affected?) > > > > > > But I enabled ld.gold as default linker like 5 years ago. Never had a > > > problem with this. > > > > > > Is ld.gold supposed to fail here? > > > > > > I switched back to ld.bfd and it seems to work. > > > > Ah, that explains it. With CONFIG_MODVERSIONS, the linker does some > > work after gcc, but before objtool. Can you try this patch? (Note this > > isn't the final patch, as this breaks the CONFIG_MODVERSIONS=n case.) Any more final patch I should test? BR, Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: objtool segfault with ORC unwinder enabled 2018-01-10 17:14 ` Markus @ 2018-01-11 4:13 ` Josh Poimboeuf 2018-01-11 4:25 ` Josh Poimboeuf 0 siblings, 1 reply; 22+ messages in thread From: Josh Poimboeuf @ 2018-01-11 4:13 UTC (permalink / raw) To: Markus; +Cc: Greg Kroah-Hartman, lkml, Ingo Molnar On Wed, Jan 10, 2018 at 06:14:56PM +0100, Markus wrote: > On Thursday, 4 January 2018 19:25:12 CET Markus wrote: > > On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote: > > > On Thu, Jan 04, 2018 at 05:56:30PM +0100, Markus wrote: > > > > On Thursday, 4 January 2018 16:46:13 CET Josh Poimboeuf wrote: > > > > > I don't see anything unusual there. Are there any Gentoo patches > > > > > against either the kernel or GCC which would strip unused symbols? > > > > > > > > The kernel is the vanilla kernel. (4.14.11 and also 4.15-rc6) > > > > Its not a gentoo specific gcc patch. (Then every gentoo user would be > > > > affected?) > > > > > > > > But I enabled ld.gold as default linker like 5 years ago. Never had a > > > > problem with this. > > > > > > > > Is ld.gold supposed to fail here? > > > > > > > > I switched back to ld.bfd and it seems to work. > > > > > > Ah, that explains it. With CONFIG_MODVERSIONS, the linker does some > > > work after gcc, but before objtool. Can you try this patch? (Note this > > > isn't the final patch, as this breaks the CONFIG_MODVERSIONS=n case.) > > Any more final patch I should test? Sorry, this fell off my radar. I'll try to get a final patch soon. (But feel free to keep bugging me if I don't!) -- Josh ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: objtool segfault with ORC unwinder enabled 2018-01-11 4:13 ` Josh Poimboeuf @ 2018-01-11 4:25 ` Josh Poimboeuf 2018-01-11 18:11 ` Markus 0 siblings, 1 reply; 22+ messages in thread From: Josh Poimboeuf @ 2018-01-11 4:25 UTC (permalink / raw) To: Markus; +Cc: Greg Kroah-Hartman, lkml, Ingo Molnar On Wed, Jan 10, 2018 at 10:13:00PM -0600, Josh Poimboeuf wrote: > On Wed, Jan 10, 2018 at 06:14:56PM +0100, Markus wrote: > > On Thursday, 4 January 2018 19:25:12 CET Markus wrote: > > > On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote: > > > > On Thu, Jan 04, 2018 at 05:56:30PM +0100, Markus wrote: > > > > > On Thursday, 4 January 2018 16:46:13 CET Josh Poimboeuf wrote: > > > > > > I don't see anything unusual there. Are there any Gentoo patches > > > > > > against either the kernel or GCC which would strip unused symbols? > > > > > > > > > > The kernel is the vanilla kernel. (4.14.11 and also 4.15-rc6) > > > > > Its not a gentoo specific gcc patch. (Then every gentoo user would be > > > > > affected?) > > > > > > > > > > But I enabled ld.gold as default linker like 5 years ago. Never had a > > > > > problem with this. > > > > > > > > > > Is ld.gold supposed to fail here? > > > > > > > > > > I switched back to ld.bfd and it seems to work. > > > > > > > > Ah, that explains it. With CONFIG_MODVERSIONS, the linker does some > > > > work after gcc, but before objtool. Can you try this patch? (Note this > > > > isn't the final patch, as this breaks the CONFIG_MODVERSIONS=n case.) > > > > Any more final patch I should test? > > Sorry, this fell off my radar. I'll try to get a final patch soon. > (But feel free to keep bugging me if I don't!) Ok, this should be the final patch (no description yet though). Want to test it? diff --git a/scripts/Makefile.build b/scripts/Makefile.build index cb8997ed0149..6f0c0c409e67 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -265,12 +265,18 @@ else objtool_args += $(call cc-ifversion, -lt, 0405, --no-unreachable) endif +ifdef CONFIG_MODVERSIONS +objtool_o := $(@D)/.tmp_$(@F) +else +objtool_o := $(@) +endif + # 'OBJECT_FILES_NON_STANDARD := y': skip objtool checking for a directory # 'OBJECT_FILES_NON_STANDARD_foo.o := 'y': skip objtool checking for a file # 'OBJECT_FILES_NON_STANDARD_foo.o := 'n': override directory skip for a file cmd_objtool = $(if $(patsubst y%,, \ $(OBJECT_FILES_NON_STANDARD_$(basetarget).o)$(OBJECT_FILES_NON_STANDARD)n), \ - $(__objtool_obj) $(objtool_args) "$(@)";) + $(__objtool_obj) $(objtool_args) "$(objtool_o)";) objtool_obj = $(if $(patsubst y%,, \ $(OBJECT_FILES_NON_STANDARD_$(basetarget).o)$(OBJECT_FILES_NON_STANDARD)n), \ $(__objtool_obj)) @@ -286,16 +292,16 @@ objtool_dep = $(objtool_obj) \ define rule_cc_o_c $(call echo-cmd,checksrc) $(cmd_checksrc) \ $(call cmd_and_fixdep,cc_o_c) \ + $(call echo-cmd,objtool) $(cmd_objtool) \ $(cmd_modversions_c) \ $(cmd_checkdoc) \ - $(call echo-cmd,objtool) $(cmd_objtool) \ $(call echo-cmd,record_mcount) $(cmd_record_mcount) endef define rule_as_o_S $(call cmd_and_fixdep,as_o_S) \ - $(cmd_modversions_S) \ - $(call echo-cmd,objtool) $(cmd_objtool) + $(call echo-cmd,objtool) $(cmd_objtool) \ + $(cmd_modversions_S) endef # List module undefined symbols (or empty line if not enabled) ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: objtool segfault with ORC unwinder enabled 2018-01-11 4:25 ` Josh Poimboeuf @ 2018-01-11 18:11 ` Markus 2018-01-11 18:20 ` Josh Poimboeuf 0 siblings, 1 reply; 22+ messages in thread From: Markus @ 2018-01-11 18:11 UTC (permalink / raw) To: Josh Poimboeuf; +Cc: Greg Kroah-Hartman, lkml, Ingo Molnar On Thursday, 11 January 2018 05:25:51 CET Josh Poimboeuf wrote: > On Wed, Jan 10, 2018 at 10:13:00PM -0600, Josh Poimboeuf wrote: > > On Wed, Jan 10, 2018 at 06:14:56PM +0100, Markus wrote: > > > On Thursday, 4 January 2018 19:25:12 CET Markus wrote: > > > > On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote: > > > > > On Thu, Jan 04, 2018 at 05:56:30PM +0100, Markus wrote: > > > > > > On Thursday, 4 January 2018 16:46:13 CET Josh Poimboeuf wrote: > > > > > > > I don't see anything unusual there. Are there any Gentoo > > > > > > > patches > > > > > > > against either the kernel or GCC which would strip unused > > > > > > > symbols? > > > > > > > > > > > > The kernel is the vanilla kernel. (4.14.11 and also 4.15-rc6) > > > > > > Its not a gentoo specific gcc patch. (Then every gentoo user would > > > > > > be > > > > > > affected?) > > > > > > > > > > > > But I enabled ld.gold as default linker like 5 years ago. Never > > > > > > had a > > > > > > problem with this. > > > > > > > > > > > > Is ld.gold supposed to fail here? > > > > > > > > > > > > I switched back to ld.bfd and it seems to work. > > > > > > > > > > Ah, that explains it. With CONFIG_MODVERSIONS, the linker does some > > > > > work after gcc, but before objtool. Can you try this patch? (Note > > > > > this > > > > > isn't the final patch, as this breaks the CONFIG_MODVERSIONS=n > > > > > case.) > > > > > > Any more final patch I should test? > > > > Sorry, this fell off my radar. I'll try to get a final patch soon. > > (But feel free to keep bugging me if I don't!) > > Ok, this should be the final patch (no description yet though). Want to > test it? Tried to apply to 4.14.13 and 4.15-rc7. Neither applied cleanly. Manually editing just breaks the build with many "open: No such file or directory". Dont know what went wrong. Can you maybe append patch as file? BR, Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: objtool segfault with ORC unwinder enabled 2018-01-11 18:11 ` Markus @ 2018-01-11 18:20 ` Josh Poimboeuf 2018-01-11 18:52 ` Markus 0 siblings, 1 reply; 22+ messages in thread From: Josh Poimboeuf @ 2018-01-11 18:20 UTC (permalink / raw) To: Markus; +Cc: Greg Kroah-Hartman, lkml, Ingo Molnar [-- Attachment #1: Type: text/plain, Size: 2079 bytes --] On Thu, Jan 11, 2018 at 07:11:03PM +0100, Markus wrote: > On Thursday, 11 January 2018 05:25:51 CET Josh Poimboeuf wrote: > > On Wed, Jan 10, 2018 at 10:13:00PM -0600, Josh Poimboeuf wrote: > > > On Wed, Jan 10, 2018 at 06:14:56PM +0100, Markus wrote: > > > > On Thursday, 4 January 2018 19:25:12 CET Markus wrote: > > > > > On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote: > > > > > > On Thu, Jan 04, 2018 at 05:56:30PM +0100, Markus wrote: > > > > > > > On Thursday, 4 January 2018 16:46:13 CET Josh Poimboeuf wrote: > > > > > > > > I don't see anything unusual there. Are there any Gentoo > > > > > > > > patches > > > > > > > > against either the kernel or GCC which would strip unused > > > > > > > > symbols? > > > > > > > > > > > > > > The kernel is the vanilla kernel. (4.14.11 and also 4.15-rc6) > > > > > > > Its not a gentoo specific gcc patch. (Then every gentoo user would > > > > > > > be > > > > > > > affected?) > > > > > > > > > > > > > > But I enabled ld.gold as default linker like 5 years ago. Never > > > > > > > had a > > > > > > > problem with this. > > > > > > > > > > > > > > Is ld.gold supposed to fail here? > > > > > > > > > > > > > > I switched back to ld.bfd and it seems to work. > > > > > > > > > > > > Ah, that explains it. With CONFIG_MODVERSIONS, the linker does some > > > > > > work after gcc, but before objtool. Can you try this patch? (Note > > > > > > this > > > > > > isn't the final patch, as this breaks the CONFIG_MODVERSIONS=n > > > > > > case.) > > > > > > > > Any more final patch I should test? > > > > > > Sorry, this fell off my radar. I'll try to get a final patch soon. > > > (But feel free to keep bugging me if I don't!) > > > > Ok, this should be the final patch (no description yet though). Want to > > test it? > > Tried to apply to 4.14.13 and 4.15-rc7. Neither applied cleanly. > Manually editing just breaks the build with many "open: No such file or > directory". > > Dont know what went wrong. Can you maybe append patch as file? Sure, patch is attached, based on 4.15-rc7. -- Josh [-- Attachment #2: objtool-gold.patch --] [-- Type: text/plain, Size: 1603 bytes --] diff --git a/scripts/Makefile.build b/scripts/Makefile.build index cb8997ed0149..6f0c0c409e67 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -265,12 +265,18 @@ else objtool_args += $(call cc-ifversion, -lt, 0405, --no-unreachable) endif +ifdef CONFIG_MODVERSIONS +objtool_o := $(@D)/.tmp_$(@F) +else +objtool_o := $(@) +endif + # 'OBJECT_FILES_NON_STANDARD := y': skip objtool checking for a directory # 'OBJECT_FILES_NON_STANDARD_foo.o := 'y': skip objtool checking for a file # 'OBJECT_FILES_NON_STANDARD_foo.o := 'n': override directory skip for a file cmd_objtool = $(if $(patsubst y%,, \ $(OBJECT_FILES_NON_STANDARD_$(basetarget).o)$(OBJECT_FILES_NON_STANDARD)n), \ - $(__objtool_obj) $(objtool_args) "$(@)";) + $(__objtool_obj) $(objtool_args) "$(objtool_o)";) objtool_obj = $(if $(patsubst y%,, \ $(OBJECT_FILES_NON_STANDARD_$(basetarget).o)$(OBJECT_FILES_NON_STANDARD)n), \ $(__objtool_obj)) @@ -286,16 +292,16 @@ objtool_dep = $(objtool_obj) \ define rule_cc_o_c $(call echo-cmd,checksrc) $(cmd_checksrc) \ $(call cmd_and_fixdep,cc_o_c) \ + $(call echo-cmd,objtool) $(cmd_objtool) \ $(cmd_modversions_c) \ $(cmd_checkdoc) \ - $(call echo-cmd,objtool) $(cmd_objtool) \ $(call echo-cmd,record_mcount) $(cmd_record_mcount) endef define rule_as_o_S $(call cmd_and_fixdep,as_o_S) \ - $(cmd_modversions_S) \ - $(call echo-cmd,objtool) $(cmd_objtool) + $(call echo-cmd,objtool) $(cmd_objtool) \ + $(cmd_modversions_S) endef # List module undefined symbols (or empty line if not enabled) ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: objtool segfault with ORC unwinder enabled 2018-01-11 18:20 ` Josh Poimboeuf @ 2018-01-11 18:52 ` Markus 2018-01-11 19:38 ` Josh Poimboeuf 0 siblings, 1 reply; 22+ messages in thread From: Markus @ 2018-01-11 18:52 UTC (permalink / raw) To: Josh Poimboeuf; +Cc: Greg Kroah-Hartman, lkml, Ingo Molnar On Thursday, 11 January 2018 19:20:57 CET Josh Poimboeuf wrote: > On Thu, Jan 11, 2018 at 07:11:03PM +0100, Markus wrote: > > On Thursday, 11 January 2018 05:25:51 CET Josh Poimboeuf wrote: > > > On Wed, Jan 10, 2018 at 10:13:00PM -0600, Josh Poimboeuf wrote: > > > > On Wed, Jan 10, 2018 at 06:14:56PM +0100, Markus wrote: > > > > > On Thursday, 4 January 2018 19:25:12 CET Markus wrote: > > > > > > On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote: > > > > > > > On Thu, Jan 04, 2018 at 05:56:30PM +0100, Markus wrote: > > > > > > > > On Thursday, 4 January 2018 16:46:13 CET Josh Poimboeuf wrote: > > > > > > > > > I don't see anything unusual there. Are there any Gentoo > > > > > > > > > patches > > > > > > > > > against either the kernel or GCC which would strip unused > > > > > > > > > symbols? > > > > > > > > > > > > > > > > The kernel is the vanilla kernel. (4.14.11 and also 4.15-rc6) > > > > > > > > Its not a gentoo specific gcc patch. (Then every gentoo user > > > > > > > > would > > > > > > > > be > > > > > > > > affected?) > > > > > > > > > > > > > > > > But I enabled ld.gold as default linker like 5 years ago. > > > > > > > > Never > > > > > > > > had a > > > > > > > > problem with this. > > > > > > > > > > > > > > > > Is ld.gold supposed to fail here? > > > > > > > > > > > > > > > > I switched back to ld.bfd and it seems to work. > > > > > > > > > > > > > > Ah, that explains it. With CONFIG_MODVERSIONS, the linker does > > > > > > > some > > > > > > > work after gcc, but before objtool. Can you try this patch? > > > > > > > (Note > > > > > > > this > > > > > > > isn't the final patch, as this breaks the CONFIG_MODVERSIONS=n > > > > > > > case.) > > > > > > > > > > Any more final patch I should test? > > > > > > > > Sorry, this fell off my radar. I'll try to get a final patch soon. > > > > (But feel free to keep bugging me if I don't!) > > > > > > Ok, this should be the final patch (no description yet though). Want to > > > test it? > > > > Tried to apply to 4.14.13 and 4.15-rc7. Neither applied cleanly. > > Manually editing just breaks the build with many "open: No such file or > > directory". > > > > Dont know what went wrong. Can you maybe append patch as file? > > Sure, patch is attached, based on 4.15-rc7. Applies cleanly to 4.15-rc7. But still: HOSTCC scripts/asn1_compiler HOSTCC scripts/extract-cert CC init/main.o open: No such file or directory make[1]: *** [scripts/Makefile.build:317: init/main.o] Error 1 make: *** [Makefile:1015: init] Error 2 Reverting that patch makes it build again. BR, Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: objtool segfault with ORC unwinder enabled 2018-01-11 18:52 ` Markus @ 2018-01-11 19:38 ` Josh Poimboeuf 2018-01-11 20:00 ` Markus 0 siblings, 1 reply; 22+ messages in thread From: Josh Poimboeuf @ 2018-01-11 19:38 UTC (permalink / raw) To: Markus; +Cc: Greg Kroah-Hartman, lkml, Ingo Molnar [-- Attachment #1: Type: text/plain, Size: 2862 bytes --] On Thu, Jan 11, 2018 at 07:52:00PM +0100, Markus wrote: > On Thursday, 11 January 2018 19:20:57 CET Josh Poimboeuf wrote: > > On Thu, Jan 11, 2018 at 07:11:03PM +0100, Markus wrote: > > > On Thursday, 11 January 2018 05:25:51 CET Josh Poimboeuf wrote: > > > > On Wed, Jan 10, 2018 at 10:13:00PM -0600, Josh Poimboeuf wrote: > > > > > On Wed, Jan 10, 2018 at 06:14:56PM +0100, Markus wrote: > > > > > > On Thursday, 4 January 2018 19:25:12 CET Markus wrote: > > > > > > > On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote: > > > > > > > > On Thu, Jan 04, 2018 at 05:56:30PM +0100, Markus wrote: > > > > > > > > > On Thursday, 4 January 2018 16:46:13 CET Josh Poimboeuf wrote: > > > > > > > > > > I don't see anything unusual there. Are there any Gentoo > > > > > > > > > > patches > > > > > > > > > > against either the kernel or GCC which would strip unused > > > > > > > > > > symbols? > > > > > > > > > > > > > > > > > > The kernel is the vanilla kernel. (4.14.11 and also 4.15-rc6) > > > > > > > > > Its not a gentoo specific gcc patch. (Then every gentoo user > > > > > > > > > would > > > > > > > > > be > > > > > > > > > affected?) > > > > > > > > > > > > > > > > > > But I enabled ld.gold as default linker like 5 years ago. > > > > > > > > > Never > > > > > > > > > had a > > > > > > > > > problem with this. > > > > > > > > > > > > > > > > > > Is ld.gold supposed to fail here? > > > > > > > > > > > > > > > > > > I switched back to ld.bfd and it seems to work. > > > > > > > > > > > > > > > > Ah, that explains it. With CONFIG_MODVERSIONS, the linker does > > > > > > > > some > > > > > > > > work after gcc, but before objtool. Can you try this patch? > > > > > > > > (Note > > > > > > > > this > > > > > > > > isn't the final patch, as this breaks the CONFIG_MODVERSIONS=n > > > > > > > > case.) > > > > > > > > > > > > Any more final patch I should test? > > > > > > > > > > Sorry, this fell off my radar. I'll try to get a final patch soon. > > > > > (But feel free to keep bugging me if I don't!) > > > > > > > > Ok, this should be the final patch (no description yet though). Want to > > > > test it? > > > > > > Tried to apply to 4.14.13 and 4.15-rc7. Neither applied cleanly. > > > Manually editing just breaks the build with many "open: No such file or > > > directory". > > > > > > Dont know what went wrong. Can you maybe append patch as file? > > > > Sure, patch is attached, based on 4.15-rc7. > > Applies cleanly to 4.15-rc7. But still: > HOSTCC scripts/asn1_compiler > HOSTCC scripts/extract-cert > CC init/main.o > open: No such file or directory > make[1]: *** [scripts/Makefile.build:317: init/main.o] Error 1 > make: *** [Makefile:1015: init] Error 2 > > > Reverting that patch makes it build again. Weird. Here's a version which should hopefully give a better error message. -- Josh [-- Attachment #2: objtool-gold-v2.patch --] [-- Type: text/plain, Size: 1971 bytes --] diff --git a/scripts/Makefile.build b/scripts/Makefile.build index cb8997ed0149..6f0c0c409e67 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -265,12 +265,18 @@ else objtool_args += $(call cc-ifversion, -lt, 0405, --no-unreachable) endif +ifdef CONFIG_MODVERSIONS +objtool_o := $(@D)/.tmp_$(@F) +else +objtool_o := $(@) +endif + # 'OBJECT_FILES_NON_STANDARD := y': skip objtool checking for a directory # 'OBJECT_FILES_NON_STANDARD_foo.o := 'y': skip objtool checking for a file # 'OBJECT_FILES_NON_STANDARD_foo.o := 'n': override directory skip for a file cmd_objtool = $(if $(patsubst y%,, \ $(OBJECT_FILES_NON_STANDARD_$(basetarget).o)$(OBJECT_FILES_NON_STANDARD)n), \ - $(__objtool_obj) $(objtool_args) "$(@)";) + $(__objtool_obj) $(objtool_args) "$(objtool_o)";) objtool_obj = $(if $(patsubst y%,, \ $(OBJECT_FILES_NON_STANDARD_$(basetarget).o)$(OBJECT_FILES_NON_STANDARD)n), \ $(__objtool_obj)) @@ -286,16 +292,16 @@ objtool_dep = $(objtool_obj) \ define rule_cc_o_c $(call echo-cmd,checksrc) $(cmd_checksrc) \ $(call cmd_and_fixdep,cc_o_c) \ + $(call echo-cmd,objtool) $(cmd_objtool) \ $(cmd_modversions_c) \ $(cmd_checkdoc) \ - $(call echo-cmd,objtool) $(cmd_objtool) \ $(call echo-cmd,record_mcount) $(cmd_record_mcount) endef define rule_as_o_S $(call cmd_and_fixdep,as_o_S) \ - $(cmd_modversions_S) \ - $(call echo-cmd,objtool) $(cmd_objtool) + $(call echo-cmd,objtool) $(cmd_objtool) \ + $(cmd_modversions_S) endef # List module undefined symbols (or empty line if not enabled) diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c index 24460155c82c..cc56e7ac8122 100644 --- a/tools/objtool/elf.c +++ b/tools/objtool/elf.c @@ -358,6 +358,7 @@ struct elf *elf_open(const char *name, int flags) elf->fd = open(name, flags); if (elf->fd == -1) { + fprintf(stderr, "objtool: can't open file %s\n", name); perror("open"); goto err; } ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: objtool segfault with ORC unwinder enabled 2018-01-11 19:38 ` Josh Poimboeuf @ 2018-01-11 20:00 ` Markus 2018-01-11 20:19 ` Josh Poimboeuf 0 siblings, 1 reply; 22+ messages in thread From: Markus @ 2018-01-11 20:00 UTC (permalink / raw) To: Josh Poimboeuf; +Cc: Greg Kroah-Hartman, lkml, Ingo Molnar On Thursday, 11 January 2018 20:38:10 CET Josh Poimboeuf wrote: > On Thu, Jan 11, 2018 at 07:52:00PM +0100, Markus wrote: > > On Thursday, 11 January 2018 19:20:57 CET Josh Poimboeuf wrote: > > > On Thu, Jan 11, 2018 at 07:11:03PM +0100, Markus wrote: > > > > On Thursday, 11 January 2018 05:25:51 CET Josh Poimboeuf wrote: > > > > > On Wed, Jan 10, 2018 at 10:13:00PM -0600, Josh Poimboeuf wrote: > > > > > > On Wed, Jan 10, 2018 at 06:14:56PM +0100, Markus wrote: > > > > > > > On Thursday, 4 January 2018 19:25:12 CET Markus wrote: > > > > > > > > On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote: > > > > > > > > > On Thu, Jan 04, 2018 at 05:56:30PM +0100, Markus wrote: > > > > > > > > > > On Thursday, 4 January 2018 16:46:13 CET Josh Poimboeuf wrote: > > > > > > > > > > > I don't see anything unusual there. Are there any > > > > > > > > > > > Gentoo > > > > > > > > > > > patches > > > > > > > > > > > against either the kernel or GCC which would strip > > > > > > > > > > > unused > > > > > > > > > > > symbols? > > > > > > > > > > > > > > > > > > > > The kernel is the vanilla kernel. (4.14.11 and also > > > > > > > > > > 4.15-rc6) > > > > > > > > > > Its not a gentoo specific gcc patch. (Then every gentoo > > > > > > > > > > user > > > > > > > > > > would > > > > > > > > > > be > > > > > > > > > > affected?) > > > > > > > > > > > > > > > > > > > > But I enabled ld.gold as default linker like 5 years ago. > > > > > > > > > > Never > > > > > > > > > > had a > > > > > > > > > > problem with this. > > > > > > > > > > > > > > > > > > > > Is ld.gold supposed to fail here? > > > > > > > > > > > > > > > > > > > > I switched back to ld.bfd and it seems to work. > > > > > > > > > > > > > > > > > > Ah, that explains it. With CONFIG_MODVERSIONS, the linker > > > > > > > > > does > > > > > > > > > some > > > > > > > > > work after gcc, but before objtool. Can you try this patch? > > > > > > > > > (Note > > > > > > > > > this > > > > > > > > > isn't the final patch, as this breaks the > > > > > > > > > CONFIG_MODVERSIONS=n > > > > > > > > > case.) > > > > > > > > > > > > > > Any more final patch I should test? > > > > > > > > > > > > Sorry, this fell off my radar. I'll try to get a final patch > > > > > > soon. > > > > > > (But feel free to keep bugging me if I don't!) > > > > > > > > > > Ok, this should be the final patch (no description yet though). > > > > > Want to > > > > > test it? > > > > > > > > Tried to apply to 4.14.13 and 4.15-rc7. Neither applied cleanly. > > > > Manually editing just breaks the build with many "open: No such file > > > > or > > > > directory". > > > > > > > > Dont know what went wrong. Can you maybe append patch as file? > > > > > > Sure, patch is attached, based on 4.15-rc7. > > > > Applies cleanly to 4.15-rc7. But still: > > HOSTCC scripts/asn1_compiler > > HOSTCC scripts/extract-cert > > CC init/main.o > > > > open: No such file or directory > > make[1]: *** [scripts/Makefile.build:317: init/main.o] Error 1 > > make: *** [Makefile:1015: init] Error 2 > > > > > > Reverting that patch makes it build again. > > Weird. Here's a version which should hopefully give a better error > message. CC init/main.o objtool: can't open file /.tmp_ open: No such file or directory BR, Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: objtool segfault with ORC unwinder enabled 2018-01-11 20:00 ` Markus @ 2018-01-11 20:19 ` Josh Poimboeuf 0 siblings, 0 replies; 22+ messages in thread From: Josh Poimboeuf @ 2018-01-11 20:19 UTC (permalink / raw) To: Markus; +Cc: Greg Kroah-Hartman, lkml, Ingo Molnar [-- Attachment #1: Type: text/plain, Size: 3735 bytes --] On Thu, Jan 11, 2018 at 09:00:33PM +0100, Markus wrote: > On Thursday, 11 January 2018 20:38:10 CET Josh Poimboeuf wrote: > > On Thu, Jan 11, 2018 at 07:52:00PM +0100, Markus wrote: > > > On Thursday, 11 January 2018 19:20:57 CET Josh Poimboeuf wrote: > > > > On Thu, Jan 11, 2018 at 07:11:03PM +0100, Markus wrote: > > > > > On Thursday, 11 January 2018 05:25:51 CET Josh Poimboeuf wrote: > > > > > > On Wed, Jan 10, 2018 at 10:13:00PM -0600, Josh Poimboeuf wrote: > > > > > > > On Wed, Jan 10, 2018 at 06:14:56PM +0100, Markus wrote: > > > > > > > > On Thursday, 4 January 2018 19:25:12 CET Markus wrote: > > > > > > > > > On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote: > > > > > > > > > > On Thu, Jan 04, 2018 at 05:56:30PM +0100, Markus wrote: > > > > > > > > > > > On Thursday, 4 January 2018 16:46:13 CET Josh Poimboeuf > wrote: > > > > > > > > > > > > I don't see anything unusual there. Are there any > > > > > > > > > > > > Gentoo > > > > > > > > > > > > patches > > > > > > > > > > > > against either the kernel or GCC which would strip > > > > > > > > > > > > unused > > > > > > > > > > > > symbols? > > > > > > > > > > > > > > > > > > > > > > The kernel is the vanilla kernel. (4.14.11 and also > > > > > > > > > > > 4.15-rc6) > > > > > > > > > > > Its not a gentoo specific gcc patch. (Then every gentoo > > > > > > > > > > > user > > > > > > > > > > > would > > > > > > > > > > > be > > > > > > > > > > > affected?) > > > > > > > > > > > > > > > > > > > > > > But I enabled ld.gold as default linker like 5 years ago. > > > > > > > > > > > Never > > > > > > > > > > > had a > > > > > > > > > > > problem with this. > > > > > > > > > > > > > > > > > > > > > > Is ld.gold supposed to fail here? > > > > > > > > > > > > > > > > > > > > > > I switched back to ld.bfd and it seems to work. > > > > > > > > > > > > > > > > > > > > Ah, that explains it. With CONFIG_MODVERSIONS, the linker > > > > > > > > > > does > > > > > > > > > > some > > > > > > > > > > work after gcc, but before objtool. Can you try this patch? > > > > > > > > > > (Note > > > > > > > > > > this > > > > > > > > > > isn't the final patch, as this breaks the > > > > > > > > > > CONFIG_MODVERSIONS=n > > > > > > > > > > case.) > > > > > > > > > > > > > > > > Any more final patch I should test? > > > > > > > > > > > > > > Sorry, this fell off my radar. I'll try to get a final patch > > > > > > > soon. > > > > > > > (But feel free to keep bugging me if I don't!) > > > > > > > > > > > > Ok, this should be the final patch (no description yet though). > > > > > > Want to > > > > > > test it? > > > > > > > > > > Tried to apply to 4.14.13 and 4.15-rc7. Neither applied cleanly. > > > > > Manually editing just breaks the build with many "open: No such file > > > > > or > > > > > directory". > > > > > > > > > > Dont know what went wrong. Can you maybe append patch as file? > > > > > > > > Sure, patch is attached, based on 4.15-rc7. > > > > > > Applies cleanly to 4.15-rc7. But still: > > > HOSTCC scripts/asn1_compiler > > > HOSTCC scripts/extract-cert > > > CC init/main.o > > > > > > open: No such file or directory > > > make[1]: *** [scripts/Makefile.build:317: init/main.o] Error 1 > > > make: *** [Makefile:1015: init] Error 2 > > > > > > > > > Reverting that patch makes it build again. > > > > Weird. Here's a version which should hopefully give a better error > > message. > > CC init/main.o > objtool: can't open file /.tmp_ > open: No such file or directory Got it figured out. I used the wrong assignment variables in the makefile (':=' instead of '=') and I didn't see the error because I was accidentally testing with objtool disabled. Oops. New patch attached. -- Josh [-- Attachment #2: objtool-gold-v3.patch --] [-- Type: text/plain, Size: 1969 bytes --] diff --git a/scripts/Makefile.build b/scripts/Makefile.build index cb8997ed0149..bc277d7c081d 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -265,12 +265,18 @@ else objtool_args += $(call cc-ifversion, -lt, 0405, --no-unreachable) endif +ifdef CONFIG_MODVERSIONS +objtool_o = $(@D)/.tmp_$(@F) +else +objtool_o = $(@) +endif + # 'OBJECT_FILES_NON_STANDARD := y': skip objtool checking for a directory # 'OBJECT_FILES_NON_STANDARD_foo.o := 'y': skip objtool checking for a file # 'OBJECT_FILES_NON_STANDARD_foo.o := 'n': override directory skip for a file cmd_objtool = $(if $(patsubst y%,, \ $(OBJECT_FILES_NON_STANDARD_$(basetarget).o)$(OBJECT_FILES_NON_STANDARD)n), \ - $(__objtool_obj) $(objtool_args) "$(@)";) + $(__objtool_obj) $(objtool_args) "$(objtool_o)";) objtool_obj = $(if $(patsubst y%,, \ $(OBJECT_FILES_NON_STANDARD_$(basetarget).o)$(OBJECT_FILES_NON_STANDARD)n), \ $(__objtool_obj)) @@ -286,16 +292,16 @@ objtool_dep = $(objtool_obj) \ define rule_cc_o_c $(call echo-cmd,checksrc) $(cmd_checksrc) \ $(call cmd_and_fixdep,cc_o_c) \ + $(call echo-cmd,objtool) $(cmd_objtool) \ $(cmd_modversions_c) \ $(cmd_checkdoc) \ - $(call echo-cmd,objtool) $(cmd_objtool) \ $(call echo-cmd,record_mcount) $(cmd_record_mcount) endef define rule_as_o_S $(call cmd_and_fixdep,as_o_S) \ - $(cmd_modversions_S) \ - $(call echo-cmd,objtool) $(cmd_objtool) + $(call echo-cmd,objtool) $(cmd_objtool) \ + $(cmd_modversions_S) endef # List module undefined symbols (or empty line if not enabled) diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c index 24460155c82c..cc56e7ac8122 100644 --- a/tools/objtool/elf.c +++ b/tools/objtool/elf.c @@ -358,6 +358,7 @@ struct elf *elf_open(const char *name, int flags) elf->fd = open(name, flags); if (elf->fd == -1) { + fprintf(stderr, "objtool: can't open file %s\n", name); perror("open"); goto err; } ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: objtool segfault with ORC unwinder enabled 2018-01-03 12:22 ` Markus 2018-01-03 13:59 ` Josh Poimboeuf @ 2018-01-03 14:14 ` Greg Kroah-Hartman 2018-01-03 14:36 ` Markus 1 sibling, 1 reply; 22+ messages in thread From: Greg Kroah-Hartman @ 2018-01-03 14:14 UTC (permalink / raw) To: Markus; +Cc: lkml, Josh Poimboeuf, Ingo Molnar 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. Not all subsystems use bugzilla.kernel.org, sorry. Email is the preferred way for almost all subsystems. > > > 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? Have you tried gcc 7? What distro is this? Hopefully not hardened Gentoo? :) > > > 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. Ugh, I can't duplicate here :( Josh, any ideas? greg k-h ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: objtool segfault with ORC unwinder enabled 2018-01-03 14:14 ` Greg Kroah-Hartman @ 2018-01-03 14:36 ` Markus 0 siblings, 0 replies; 22+ messages in thread From: Markus @ 2018-01-03 14:36 UTC (permalink / raw) To: Greg Kroah-Hartman; +Cc: lkml, Josh Poimboeuf, Ingo Molnar On Wed, Jan 03, 2018 15:14:01 CET Greg Kroah-Hartman 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. > > Not all subsystems use bugzilla.kernel.org, sorry. Email is the > preferred way for almost all subsystems. > > > > > 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? > > Have you tried gcc 7? No I have no gcc 7 installed, yet. (In the bug report gcc 8.0.0 and gcc 5.4.0 were mentioned.) > What distro is this? Hopefully not hardened Gentoo? :) Just a normal gentoo. > > > > 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. > > Ugh, I can't duplicate here :( How about the previously attached irq.o? BR, Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2018-01-11 20:19 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-01-03 10:49 objtool segfault with ORC unwinder enabled Markus 2018-01-03 11:19 ` Greg Kroah-Hartman 2018-01-03 12:22 ` Markus 2018-01-03 13:59 ` Josh Poimboeuf 2018-01-03 14:14 ` Markus 2018-01-03 16:36 ` Josh Poimboeuf 2018-01-03 17:26 ` Markus 2018-01-04 15:46 ` Josh Poimboeuf 2018-01-04 16:56 ` Markus 2018-01-04 17:32 ` Josh Poimboeuf 2018-01-04 18:25 ` Markus 2018-01-10 17:14 ` Markus 2018-01-11 4:13 ` Josh Poimboeuf 2018-01-11 4:25 ` Josh Poimboeuf 2018-01-11 18:11 ` Markus 2018-01-11 18:20 ` Josh Poimboeuf 2018-01-11 18:52 ` Markus 2018-01-11 19:38 ` Josh Poimboeuf 2018-01-11 20:00 ` Markus 2018-01-11 20:19 ` Josh Poimboeuf 2018-01-03 14:14 ` Greg Kroah-Hartman 2018-01-03 14:36 ` Markus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox