objtool segfault with ORC unwinder enabled

DISCUSSION Markus 3 participants 22 messages Jan 3, 2018 – Jan 11, 2018

Subsystems (2)

Kbuild objtool

lore

Share & tools

lore

Markus

author

2018-01-03 10:49 UTC #0 lore raw

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

Greg Kroah-Hartman

2018-01-03 11:19 UTC #1 lore raw

Quoted 5 lines · Markus

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.

Quoted 1 line

objtool will segfault because a NULL pointer is dereferenced.

And how are you reproducing this?

Quoted 2 lines

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

Markus

author

2018-01-03 12:22 UTC #2 lore raw

Quoted 9 lines · On Wed, Jan 03, 2018 at 12:19:41 CET Greg Kroah-Hartman wrote:

Quoted 5 lines · Markus
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.

Quoted 3 lines

Quoted 1 line
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?

Quoted 4 lines

Quoted 3 lines
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.

Quoted 1 line

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-

Quoted 1 line

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

Josh Poimboeuf

2018-01-03 13:59 UTC #3 lore raw

Quoted 48 lines · Markus

Quoted 9 lines · On Wed, Jan 03, 2018 at 12:19:41 CET Greg Kroah-Hartman wrote:
Quoted 5 lines · Markus
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.
Quoted 3 lines
Quoted 1 line
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?
Quoted 4 lines
Quoted 3 lines
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.
Quoted 1 line
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-
Quoted 1 line
type);

Quoted 14 lines

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

Signature · 1 line

Josh

Markus

author

2018-01-03 14:15 UTC #4 lore raw

Quoted 71 lines · On Wed, Jan 03, 2018 at 14:59:24 CET Josh Poimboeuf wrote:

Quoted 54 lines · Markus
Quoted 10 lines · On Wed, Jan 03, 2018 at 12:19:41 CET Greg Kroah-Hartman wrote:
Quoted 6 lines · Markus
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.
Quoted 3 lines
Quoted 1 line
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?
Quoted 5 lines
Quoted 3 lines
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.
Quoted 1 line
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->
Quoted 1 line
type);
Quoted 14 lines
(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

Quoted 2 lines

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

Josh Poimboeuf

2018-01-03 16:36 UTC #5 lore raw

Quoted 72 lines · Markus

Quoted 70 lines · On Wed, Jan 03, 2018 at 14:59:24 CET Josh Poimboeuf wrote:
Quoted 68 lines · Markus
Quoted 10 lines · On Wed, Jan 03, 2018 at 12:19:41 CET Greg Kroah-Hartman wrote:
Quoted 6 lines · Markus
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.
Quoted 3 lines
Quoted 1 line
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?
Quoted 5 lines
Quoted 3 lines
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.
Quoted 1 line
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->
Quoted 1 line
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

Quoted 3 lines

Quoted 2 lines
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?

Signature · 1 line

Josh

Markus

author

2018-01-03 17:26 UTC #6 lore raw

Quoted 41 lines · On Wed, Jan 03, 2018 at 17:36:30 CET Josh Poimboeuf wrote:

Quoted 40 lines · Markus
Quoted 38 lines · On Wed, Jan 03, 2018 at 14:59:24 CET Josh Poimboeuf wrote:
Quoted 19 lines · Markus
/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->
Quoted 1 line
type);
Quoted 15 lines
(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)?

Quoted 7 lines

Quoted 1 line
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

Josh Poimboeuf

2018-01-04 15:46 UTC #7 lore raw

Quoted 38 lines · Markus

Quoted 10 lines
Quoted 4 lines
Quoted 2 lines
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

Quoted 1 line

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?

Signature · 1 line

Josh

Markus

author

2018-01-04 16:56 UTC #8 lore raw

Quoted 46 lines · On Thursday, 4 January 2018 16:46:13 CET Josh Poimboeuf wrote:

Quoted 45 lines · Markus
Quoted 11 lines
Quoted 5 lines
Quoted 3 lines
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
(quoted diff) +0 -3
-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
(quoted diff) +0 -5
-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
(quoted diff) +0 -4
-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
(quoted diff) +0 -2
-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
(quoted diff) +0 -2
-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

Quoted 4 lines

Quoted 1 line
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

Josh Poimboeuf

2018-01-04 17:32 UTC #9 lore raw

Quoted 56 lines · Markus

Quoted 46 lines · On Thursday, 4 January 2018 16:46:13 CET Josh Poimboeuf wrote:
Quoted 45 lines · Markus
Quoted 11 lines
Quoted 5 lines
Quoted 3 lines
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
(quoted diff) +0 -3
-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
(quoted diff) +0 -5
-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
(quoted diff) +0 -4
-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
(quoted diff) +0 -2
-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
(quoted diff) +0 -2
-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
Quoted 4 lines
Quoted 1 line
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?)

Quoted 6 lines

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

scripts/Makefile.build +4 -4

index cb8997ed0149..3cf3cc6077ea 100644
@@ -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)

Markus

author

2018-01-04 18:25 UTC #10 lore raw

Quoted 25 lines · On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote:

Quoted 8 lines · Markus
Quoted 2 lines · 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?)
Quoted 6 lines
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.)
scripts/Makefile.build +0 -0
index cb8997ed0149..3cf3cc6077ea 100644

scripts/Makefile.build endif · line 272

Quoted 3 lines

scripts/Makefile.build +0 -0

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

scripts/Makefile.build endif

Quoted 4 lines

scripts/Makefile.build +1 -0

 , \ -	$(__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)

Quoted 11 lines

, \ $(__objtool_obj))

scripts/Makefile.build +1 -1

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

scripts/Makefile.build objtool_dep = $(objtool_obj) \ · line 301

Quoted 10 lines

scripts/Makefile.build +2 -2

 
 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

Markus

author

2018-01-10 17:15 UTC #11 lore raw

Quoted 13 lines · On Thursday, 4 January 2018 19:25:12 CET Markus wrote:

Quoted 12 lines · On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote:
Quoted 11 lines · Markus
Quoted 2 lines · 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.

Quoted 7 lines

Quoted 7 lines
Quoted 3 lines
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

Josh Poimboeuf

2018-01-11 04:13 UTC #12 lore raw

Quoted 16 lines · Markus

Quoted 15 lines · On Thursday, 4 January 2018 19:25:12 CET Markus wrote:
Quoted 14 lines · On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote:
Quoted 13 lines · Markus
Quoted 2 lines · 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?

Quoted 7 lines

Quoted 5 lines
Quoted 5 lines
Quoted 1 line
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!)

Signature · 1 line

Josh

Josh Poimboeuf

2018-01-11 04:25 UTC #13 lore raw

Quoted 19 lines · Josh Poimboeuf

Quoted 18 lines · Markus
Quoted 17 lines · On Thursday, 4 January 2018 19:25:12 CET Markus wrote:
Quoted 16 lines · On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote:
Quoted 14 lines · Markus
Quoted 2 lines · 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.

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
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?

scripts/Makefile.build +10 -4

index cb8997ed0149..6f0c0c409e67 100644
@@ -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)

Markus

author

2018-01-11 18:11 UTC #14 lore raw

Quoted 30 lines · On Thursday, 11 January 2018 05:25:51 CET Josh Poimboeuf wrote:

Quoted 29 lines · Josh Poimboeuf
Quoted 28 lines · Markus
Quoted 26 lines · On Thursday, 4 January 2018 19:25:12 CET Markus wrote:
Quoted 25 lines · On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote:
Quoted 11 lines · Markus
Quoted 4 lines · 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?)
Quoted 7 lines
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.)

Quoted 7 lines

Quoted 4 lines
Quoted 1 line
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

Josh Poimboeuf

2018-01-11 18:21 UTC #15 lore raw

Quoted 36 lines · Markus

Quoted 35 lines · On Thursday, 11 January 2018 05:25:51 CET Josh Poimboeuf wrote:
Quoted 33 lines · Josh Poimboeuf
Quoted 22 lines · Markus
Quoted 21 lines · On Thursday, 4 January 2018 19:25:12 CET Markus wrote:
Quoted 20 lines · On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote:
Quoted 18 lines · Markus
Quoted 4 lines · 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.
Quoted 7 lines
Quoted 5 lines
Quoted 5 lines
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!)

Quoted 8 lines

Quoted 2 lines
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.

Signature · 1 line

Josh

scripts/Makefile.build +10 -4

index cb8997ed0149..6f0c0c409e67 100644
@@ -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)

Markus

author

2018-01-11 18:52 UTC #16 lore raw

Quoted 44 lines · On Thursday, 11 January 2018 19:20:57 CET Josh Poimboeuf wrote:

Quoted 43 lines · Markus
Quoted 41 lines · On Thursday, 11 January 2018 05:25:51 CET Josh Poimboeuf wrote:
Quoted 33 lines · Josh Poimboeuf
Quoted 32 lines · Markus
Quoted 30 lines · On Thursday, 4 January 2018 19:25:12 CET Markus wrote:
Quoted 29 lines · On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote:
Quoted 12 lines · Markus
Quoted 4 lines · 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?)
Quoted 8 lines
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.)
Quoted 4 lines
Quoted 1 line
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?

Quoted 7 lines

Quoted 5 lines
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

Josh Poimboeuf

2018-01-11 19:38 UTC #17 lore raw

Quoted 57 lines · Markus

Quoted 44 lines · On Thursday, 11 January 2018 19:20:57 CET Josh Poimboeuf wrote:
Quoted 43 lines · Markus
Quoted 41 lines · On Thursday, 11 January 2018 05:25:51 CET Josh Poimboeuf wrote:
Quoted 33 lines · Josh Poimboeuf
Quoted 32 lines · Markus
Quoted 30 lines · On Thursday, 4 January 2018 19:25:12 CET Markus wrote:
Quoted 29 lines · On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote:
Quoted 12 lines · Markus
Quoted 4 lines · 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?)
Quoted 8 lines
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.)
Quoted 4 lines
Quoted 1 line
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?
Quoted 7 lines
Quoted 5 lines
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

Quoted 6 lines

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.

Signature · 1 line

Josh

scripts/Makefile.build +10 -4

index cb8997ed0149..6f0c0c409e67 100644
@@ -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)

tools/objtool/elf.c +1 -0

index 24460155c82c..cc56e7ac8122 100644
@@ -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;
 	}

Markus

author

2018-01-11 20:01 UTC #18 lore raw

Quoted 10 lines · On Thursday, 11 January 2018 20:38:10 CET Josh Poimboeuf wrote:

Quoted 9 lines · Markus
Quoted 8 lines · On Thursday, 11 January 2018 19:20:57 CET Josh Poimboeuf wrote:
Quoted 7 lines · Markus
Quoted 6 lines · On Thursday, 11 January 2018 05:25:51 CET Josh Poimboeuf wrote:
Quoted 5 lines · Josh Poimboeuf
Quoted 4 lines · Markus
Quoted 3 lines · On Thursday, 4 January 2018 19:25:12 CET Markus wrote:
Quoted 2 lines · On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote:
Quoted 1 line · Markus
On Thursday, 4 January 2018 16:46:13 CET Josh Poimboeuf

Quoted 63 lines · wrote:

Quoted 63 lines
Quoted 44 lines
Quoted 44 lines
Quoted 43 lines
Quoted 34 lines
Quoted 34 lines
Quoted 33 lines
Quoted 33 lines
Quoted 15 lines
Quoted 6 lines
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?)
Quoted 8 lines
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.)
Quoted 5 lines
Quoted 1 line
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?
Quoted 8 lines
Quoted 6 lines
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

Quoted 4 lines

Quoted 1 line
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

Josh Poimboeuf

2018-01-11 20:19 UTC #19 lore raw

Quoted 75 lines · Markus

Quoted 10 lines · On Thursday, 11 January 2018 20:38:10 CET Josh Poimboeuf wrote:
Quoted 9 lines · Markus
Quoted 8 lines · On Thursday, 11 January 2018 19:20:57 CET Josh Poimboeuf wrote:
Quoted 7 lines · Markus
Quoted 6 lines · On Thursday, 11 January 2018 05:25:51 CET Josh Poimboeuf wrote:
Quoted 5 lines · Josh Poimboeuf
Quoted 4 lines · Markus
Quoted 3 lines · On Thursday, 4 January 2018 19:25:12 CET Markus wrote:
Quoted 2 lines · On Thursday, 4 January 2018 18:32:03 CET Josh Poimboeuf wrote:
Quoted 1 line · Markus
On Thursday, 4 January 2018 16:46:13 CET Josh Poimboeuf
Quoted 63 lines · wrote:
Quoted 63 lines
Quoted 44 lines
Quoted 44 lines
Quoted 43 lines
Quoted 34 lines
Quoted 34 lines
Quoted 33 lines
Quoted 33 lines
Quoted 15 lines
Quoted 6 lines
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?)
Quoted 8 lines
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.)
Quoted 5 lines
Quoted 1 line
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?
Quoted 8 lines
Quoted 6 lines
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

Quoted 8 lines

Quoted 4 lines
Quoted 1 line
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.

Signature · 1 line

Josh

scripts/Makefile.build +10 -4

index cb8997ed0149..bc277d7c081d 100644
@@ -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)

tools/objtool/elf.c +1 -0

index 24460155c82c..cc56e7ac8122 100644
@@ -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;
 	}

Greg Kroah-Hartman

2018-01-03 14:13 UTC #20 lore raw

In reply to Markus

Quoted 8 lines · Markus

Quoted 7 lines · On Wed, Jan 03, 2018 at 12:19:41 CET Greg Kroah-Hartman wrote:
Quoted 5 lines · Markus
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

Quoted 5 lines

Quoted 2 lines
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.

Quoted 9 lines

Quoted 3 lines
Quoted 1 line
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? :)

Quoted 4 lines

Quoted 4 lines
Quoted 3 lines
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?

Quoted 8 lines

See attachment.
Quoted 1 line
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

Markus

author

2018-01-03 14:36 UTC #21 lore raw

Quoted 23 lines · On Wed, Jan 03, 2018 15:14:01 CET Greg Kroah-Hartman wrote:

Quoted 9 lines · Markus
Quoted 8 lines · On Wed, Jan 03, 2018 at 12:19:41 CET Greg Kroah-Hartman wrote:
Quoted 6 lines · Markus
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
Quoted 5 lines
Quoted 2 lines
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.
Quoted 4 lines
Quoted 3 lines
Quoted 1 line
objtool will segfault because a NULL pointer is dereferenced.
And how are you reproducing this?

Quoted 7 lines

Quoted 5 lines
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.)

Quoted 1 line

What distro is this? Hopefully not hardened Gentoo? :)

Just a normal gentoo.

Quoted 10 lines

Quoted 10 lines
Quoted 5 lines
Quoted 3 lines
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.
Quoted 1 line
And does this show up on 4.14.11, and 4.15-rc6?

Quoted 7 lines

Quoted 5 lines
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