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