Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On Thu, Feb 11, 2021 at 12:01:12PM -0600, Bruce Dubbs wrote: > On 2/11/21 8:38 AM, Ken Moffat wrote: > > On Thu, Feb 11, 2021 at 11:17:27AM +0100, Pierre Labastie wrote: > > > > I've now applied that to 5.10.15-rc1 and confirmed it builds and > > boots. Gotta go out right now for provisions, will use my other > > mail to inform the relevant people that this fixes builds with > > binutils-2.36.1 when I get back. > > The 5.10.15 kernel is now out, but I can confirm that the patch above has > NOT been incorporated. > > Do we know when 5.11 will be released? We are scheduled to go into package > freeze on Sunday, but if it is not fixed yet, I think we should wait for it. > > -- Bruce > 5.11 is expected on Sunday night. We normally wait for .1 versions (and the patch has missed 5.10.16 by the look of things (5.10.16-rc1 was released before I sent my mail), no idea if it will arrive in 5.10.18 - it looks as if it had been filed under "breaks clang, but that is maybe broken anyway" (although Linus apparently now uses it). And we are expecting the (low severity) new version of OpenSSL next Tuesday. Broadening this, any thought on the change to adapt glibc for (at least) older AMD K10 hardware ? ĸen -- Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout. -- rfc 2324 (1st April 1998) -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On 2/11/21 2:19 PM, Ken Moffat wrote: On Thu, Feb 11, 2021 at 12:01:12PM -0600, Bruce Dubbs wrote: On 2/11/21 8:38 AM, Ken Moffat wrote: On Thu, Feb 11, 2021 at 11:17:27AM +0100, Pierre Labastie wrote: I've now applied that to 5.10.15-rc1 and confirmed it builds and boots. Gotta go out right now for provisions, will use my other mail to inform the relevant people that this fixes builds with binutils-2.36.1 when I get back. The 5.10.15 kernel is now out, but I can confirm that the patch above has NOT been incorporated. Do we know when 5.11 will be released? We are scheduled to go into package freeze on Sunday, but if it is not fixed yet, I think we should wait for it. -- Bruce 5.11 is expected on Sunday night. We normally wait for .1 versions (and the patch has missed 5.10.16 by the look of things (5.10.16-rc1 was released before I sent my mail), no idea if it will arrive in 5.10.18 - it looks as if it had been filed under "breaks clang, but that is maybe broken anyway" (although Linus apparently now uses it). And we are expecting the (low severity) new version of OpenSSL next Tuesday. Broadening this, any thought on the change to adapt glibc for (at least) older AMD K10 hardware ? On the glibc change, we should definitely proceed I think. I can reproduce it on Sandy Bridge Intel as well, and my SysV box is affected too. This is a tough one, hopefully Bruce has more insight. We could just do -rc1 with Linux 5.11 (no point version), but not sure if that's the best way to approach things either - Doug -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On Thu, Feb 11, 2021 at 11:17:27AM +0100, Pierre Labastie wrote:
> On Thu, 2021-02-11 at 12:28 +0800, Xi Ruoyao wrote:
> > On 2021-02-10 21:57 -0500, Jean-Marc Pigeon wrote:
> > > Bonjour Xi (hello the list),
> > >
> > > On Thu, 2021-02-11 at 10:51 +0800, Xi Ruoyao wrote:
> > > > On 2021-02-10 22:47 +0100, Pierre Labastie wrote:
> > > > > On Wed, 2021-02-10 at 21:03 +, Ken Moffat wrote:
> > > > > > On Wed, Feb 10, 2021 at 08:49:56PM +, Ken Moffat wrote:
> > > > >
> > > > > I managed to compile objtool with -g, to recompile apic.c to
> > > > > apic.o
> > > > > (because it gets erased when objtool fails), and to run the
> > > > > objtool
> > > > > command on it under gdb. The segfault is esay to understand:
> > > > >
> > > > > Program received signal SIGSEGV, Segmentation fault.
> > > > > 0x00412f71 in elf_rebuild_rela_reloc_section
> > > > > (sec=0xe22b10,
> > > > > nr=16)
> > > > > at elf.c:883
> > > > > 883 relocs[idx].r_info = GELF_R_INFO(reloc-
> > > > > > sym-
> > > > > > idx, reloc->type);
> > > > >
> > > > > and the reloc struct is:
> > > > > (gdb) p *reloc
> > > > > $2 = {list = {next = 0xe23240, prev = 0xe23160}, hash = {next =
> > > > > 0x0,
> > > > > pprev = 0xe23250}, {rela = {r_offset = 0, r_info = 0,
> > > > > r_addend
> > > > > =
> > > > > 0},
> > > > > rel = {r_offset = 0, r_info = 0}}, sec = 0xe22b10, sym =
> > > > > 0x0,
> > > > > offset = 48,
> > > > > type = 2, addend = 467, idx = 0, jump_table_start = false}
> > > > >
> > > > > So reloc->sym is zero, and reloc->sym->idx is a null
> > > > > dereference...
> > > > >
> > > > > Now to understand why reloc->sym is zero is more complicated...
> > > >
> > > > I can reproduce it too with Ken's config and just "make
> > > > arch/x86/kernel/apic/apic.o".
> > > >
> > > > I seen a strange warning in build:
> > > >
> > > > > Warning: Kernel ABI header at 'tools/arch/x86/lib/insn.c'
> > > > > differs
> > > > > from latest
> > > > > version at 'arch/x86/lib/insn.c'
> > > >
> > > > Not sure if it causes the segfault. I'll try 5.10.15 and if it's
> > > > not
> > > > fixed I'll
> > > > report it as a kernel bug.
> > > do you confirm it is binutil-2.36.1 related or
> > > is it a kernel only problem?
> >
> > I can't confirm or disconfirm. It's beyond my knowledge. But I
> > decided to
> > report it to the kernel bugzilla. If kernel dev thinks it's a
> > binutils bug they
> > can report to binutils anyway.
> >
> > And, this issue seems "fixed" in 5.11-rc7 so I think the kernel dev
> > may have
> > some idea of it.
>
> Looks like
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=44f6a7c0755d8dd453c70557e11687bb080a6f21
>
>
> fixes it (at least with Ken's configuration). I've applied this patch
> to 5.10.13 tree (I had also to download the skl_dmc_ver1_27.bin
> firmware to /lib/frimware/i915 to allow the build with Ken's config).
>
> Pierre
>
Pierre, thanks for finding the patch. After I'd gone to bed it
occurred to me that I would need to download earlier 5.11-rc kernels
to find which one fixed it, and then do a reverse bisect to find
which commit fixed it (the logic of that always makes me even more
confused than normal), so many thanks for saving me that confusion!
I've now applied that to 5.10.15-rc1 and confirmed it builds and
boots. Gotta go out right now for provisions, will use my other
mail to inform the relevant people that this fixes builds with
binutils-2.36.1 when I get back.
Cheers.
ĸen
--
Any attempt to brew coffee with a teapot should result in the error
code "418 I'm a teapot". The resulting entity body MAY be short and
stout. -- rfc 2324 (1st April 1998)
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On 2/11/21 8:38 AM, Ken Moffat wrote: On Thu, Feb 11, 2021 at 11:17:27AM +0100, Pierre Labastie wrote: On Thu, 2021-02-11 at 12:28 +0800, Xi Ruoyao wrote: On 2021-02-10 21:57 -0500, Jean-Marc Pigeon wrote: [snip] And, this issue seems "fixed" in 5.11-rc7 so I think the kernel dev may have some idea of it. Looks like https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=44f6a7c0755d8dd453c70557e11687bb080a6f21 fixes it (at least with Ken's configuration). I've applied this patch to 5.10.13 tree (I had also to download the skl_dmc_ver1_27.bin firmware to /lib/frimware/i915 to allow the build with Ken's config). Pierre Pierre, thanks for finding the patch. After I'd gone to bed it occurred to me that I would need to download earlier 5.11-rc kernels to find which one fixed it, and then do a reverse bisect to find which commit fixed it (the logic of that always makes me even more confused than normal), so many thanks for saving me that confusion! I've now applied that to 5.10.15-rc1 and confirmed it builds and boots. Gotta go out right now for provisions, will use my other mail to inform the relevant people that this fixes builds with binutils-2.36.1 when I get back. The 5.10.15 kernel is now out, but I can confirm that the patch above has NOT been incorporated. Do we know when 5.11 will be released? We are scheduled to go into package freeze on Sunday, but if it is not fixed yet, I think we should wait for it. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On Thu, 2021-02-11 at 12:28 +0800, Xi Ruoyao wrote:
> On 2021-02-10 21:57 -0500, Jean-Marc Pigeon wrote:
> > Bonjour Xi (hello the list),
> >
> > On Thu, 2021-02-11 at 10:51 +0800, Xi Ruoyao wrote:
> > > On 2021-02-10 22:47 +0100, Pierre Labastie wrote:
> > > > On Wed, 2021-02-10 at 21:03 +, Ken Moffat wrote:
> > > > > On Wed, Feb 10, 2021 at 08:49:56PM +, Ken Moffat wrote:
> > > > > > >
> > > > > > > Looks like I need to change the Frame pointer unwinder to
> > > > > > > the
> > > > > > > ORC unwinder to have the same config as you.
> > > > > > >
> > > > > >
> > > > > > The benefits of the ORC unwinder are mentioned at
> > > > > > https://www.kernel.org/doc/html/latest/x86/orc-unwinder.html
> > > > > >
> > > > > > It has been around for quite some time, but I probably
> > > > > > picked
> > > > > > it
> > > > > > up when it first appeared (test an -rc kernel, pick up new
> > > > > > options
> > > > > > which might be useful). I guess that old configs from
> > > > > > before
> > > > > > its
> > > > > > introduction still default to the old unwinder.
> > > > > >
> > > > > In fact it caused trouble about 3 years ago, there are links
> > > > > to
> > > > > the
> > > > > -dev archive from around January 2018 when elfutils was still
> > > > > in
> > > > > BLFS, and at that time LFS had to use the frame pointer. So
> > > > > when
> > > > > libelf arrived in LFS I started to use it (or use it again,
> > > > > not
> > > > > sure
> > > > > which).
> > > > >
> > > >
> > > > I managed to compile objtool with -g, to recompile apic.c to
> > > > apic.o
> > > > (because it gets erased when objtool fails), and to run the
> > > > objtool
> > > > command on it under gdb. The segfault is esay to understand:
> > > >
> > > > Program received signal SIGSEGV, Segmentation fault.
> > > > 0x00412f71 in elf_rebuild_rela_reloc_section
> > > > (sec=0xe22b10,
> > > > nr=16)
> > > > at elf.c:883
> > > > 883 relocs[idx].r_info = GELF_R_INFO(reloc-
> > > > > sym-
> > > > > idx, reloc->type);
> > > >
> > > > and the reloc struct is:
> > > > (gdb) p *reloc
> > > > $2 = {list = {next = 0xe23240, prev = 0xe23160}, hash = {next =
> > > > 0x0,
> > > > pprev = 0xe23250}, {rela = {r_offset = 0, r_info = 0,
> > > > r_addend
> > > > =
> > > > 0},
> > > > rel = {r_offset = 0, r_info = 0}}, sec = 0xe22b10, sym =
> > > > 0x0,
> > > > offset = 48,
> > > > type = 2, addend = 467, idx = 0, jump_table_start = false}
> > > >
> > > > So reloc->sym is zero, and reloc->sym->idx is a null
> > > > dereference...
> > > >
> > > > Now to understand why reloc->sym is zero is more complicated...
> > >
> > > I can reproduce it too with Ken's config and just "make
> > > arch/x86/kernel/apic/apic.o".
> > >
> > > I seen a strange warning in build:
> > >
> > > > Warning: Kernel ABI header at 'tools/arch/x86/lib/insn.c'
> > > > differs
> > > > from latest
> > > > version at 'arch/x86/lib/insn.c'
> > >
> > > Not sure if it causes the segfault. I'll try 5.10.15 and if it's
> > > not
> > > fixed I'll
> > > report it as a kernel bug.
> > do you confirm it is binutil-2.36.1 related or
> > is it a kernel only problem?
>
> I can't confirm or disconfirm. It's beyond my knowledge. But I
> decided to
> report it to the kernel bugzilla. If kernel dev thinks it's a
> binutils bug they
> can report to binutils anyway.
>
> And, this issue seems "fixed" in 5.11-rc7 so I think the kernel dev
> may have
> some idea of it.
Looks like
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=44f6a7c0755d8dd453c70557e11687bb080a6f21
fixes it (at least with Ken's configuration). I've applied this patch
to 5.10.13 tree (I had also to download the skl_dmc_ver1_27.bin
firmware to /lib/frimware/i915 to allow the build with Ken's config).
Pierre
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On 2021-02-10 21:57 -0500, Jean-Marc Pigeon wrote:
> Bonjour Xi (hello the list),
>
> On Thu, 2021-02-11 at 10:51 +0800, Xi Ruoyao wrote:
> > On 2021-02-10 22:47 +0100, Pierre Labastie wrote:
> > > On Wed, 2021-02-10 at 21:03 +, Ken Moffat wrote:
> > > > On Wed, Feb 10, 2021 at 08:49:56PM +, Ken Moffat wrote:
> > > > > >
> > > > > > Looks like I need to change the Frame pointer unwinder to the
> > > > > > ORC unwinder to have the same config as you.
> > > > > >
> > > > >
> > > > > The benefits of the ORC unwinder are mentioned at
> > > > > https://www.kernel.org/doc/html/latest/x86/orc-unwinder.html
> > > > >
> > > > > It has been around for quite some time, but I probably picked
> > > > > it
> > > > > up when it first appeared (test an -rc kernel, pick up new
> > > > > options
> > > > > which might be useful). I guess that old configs from before
> > > > > its
> > > > > introduction still default to the old unwinder.
> > > > >
> > > > In fact it caused trouble about 3 years ago, there are links to
> > > > the
> > > > -dev archive from around January 2018 when elfutils was still in
> > > > BLFS, and at that time LFS had to use the frame pointer. So when
> > > > libelf arrived in LFS I started to use it (or use it again, not
> > > > sure
> > > > which).
> > > >
> > >
> > > I managed to compile objtool with -g, to recompile apic.c to apic.o
> > > (because it gets erased when objtool fails), and to run the objtool
> > > command on it under gdb. The segfault is esay to understand:
> > >
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x00412f71 in elf_rebuild_rela_reloc_section (sec=0xe22b10,
> > > nr=16)
> > > at elf.c:883
> > > 883 relocs[idx].r_info = GELF_R_INFO(reloc-
> > > > sym-
> > > > idx, reloc->type);
> > >
> > > and the reloc struct is:
> > > (gdb) p *reloc
> > > $2 = {list = {next = 0xe23240, prev = 0xe23160}, hash = {next =
> > > 0x0,
> > > pprev = 0xe23250}, {rela = {r_offset = 0, r_info = 0, r_addend
> > > =
> > > 0},
> > > rel = {r_offset = 0, r_info = 0}}, sec = 0xe22b10, sym = 0x0,
> > > offset = 48,
> > > type = 2, addend = 467, idx = 0, jump_table_start = false}
> > >
> > > So reloc->sym is zero, and reloc->sym->idx is a null dereference...
> > >
> > > Now to understand why reloc->sym is zero is more complicated...
> >
> > I can reproduce it too with Ken's config and just "make
> > arch/x86/kernel/apic/apic.o".
> >
> > I seen a strange warning in build:
> >
> > > Warning: Kernel ABI header at 'tools/arch/x86/lib/insn.c' differs
> > > from latest
> > > version at 'arch/x86/lib/insn.c'
> >
> > Not sure if it causes the segfault. I'll try 5.10.15 and if it's not
> > fixed I'll
> > report it as a kernel bug.
> do you confirm it is binutil-2.36.1 related or
> is it a kernel only problem?
I can't confirm or disconfirm. It's beyond my knowledge. But I decided to
report it to the kernel bugzilla. If kernel dev thinks it's a binutils bug they
can report to binutils anyway.
And, this issue seems "fixed" in 5.11-rc7 so I think the kernel dev may have
some idea of it.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
Bonjour Xi (hello the list),
On Thu, 2021-02-11 at 10:51 +0800, Xi Ruoyao wrote:
> On 2021-02-10 22:47 +0100, Pierre Labastie wrote:
> > On Wed, 2021-02-10 at 21:03 +, Ken Moffat wrote:
> > > On Wed, Feb 10, 2021 at 08:49:56PM +, Ken Moffat wrote:
> > > > >
> > > > > Looks like I need to change the Frame pointer unwinder to the
> > > > > ORC unwinder to have the same config as you.
> > > > >
> > > >
> > > > The benefits of the ORC unwinder are mentioned at
> > > > https://www.kernel.org/doc/html/latest/x86/orc-unwinder.html
> > > >
> > > > It has been around for quite some time, but I probably picked
> > > > it
> > > > up when it first appeared (test an -rc kernel, pick up new
> > > > options
> > > > which might be useful). I guess that old configs from before
> > > > its
> > > > introduction still default to the old unwinder.
> > > >
> > > In fact it caused trouble about 3 years ago, there are links to
> > > the
> > > -dev archive from around January 2018 when elfutils was still in
> > > BLFS, and at that time LFS had to use the frame pointer. So when
> > > libelf arrived in LFS I started to use it (or use it again, not
> > > sure
> > > which).
> > >
> >
> > I managed to compile objtool with -g, to recompile apic.c to apic.o
> > (because it gets erased when objtool fails), and to run the objtool
> > command on it under gdb. The segfault is esay to understand:
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x00412f71 in elf_rebuild_rela_reloc_section (sec=0xe22b10,
> > nr=16)
> > at elf.c:883
> > 883 relocs[idx].r_info = GELF_R_INFO(reloc-
> > >sym-
> > > idx, reloc->type);
> >
> > and the reloc struct is:
> > (gdb) p *reloc
> > $2 = {list = {next = 0xe23240, prev = 0xe23160}, hash = {next =
> > 0x0,
> > pprev = 0xe23250}, {rela = {r_offset = 0, r_info = 0, r_addend
> > =
> > 0},
> > rel = {r_offset = 0, r_info = 0}}, sec = 0xe22b10, sym = 0x0,
> > offset = 48,
> > type = 2, addend = 467, idx = 0, jump_table_start = false}
> >
> > So reloc->sym is zero, and reloc->sym->idx is a null dereference...
> >
> > Now to understand why reloc->sym is zero is more complicated...
>
> I can reproduce it too with Ken's config and just "make
> arch/x86/kernel/apic/apic.o".
>
> I seen a strange warning in build:
>
> > Warning: Kernel ABI header at 'tools/arch/x86/lib/insn.c' differs
> > from latest
> > version at 'arch/x86/lib/insn.c'
>
> Not sure if it causes the segfault. I'll try 5.10.15 and if it's not
> fixed I'll
> report it as a kernel bug.
do you confirm it is binutil-2.36.1 related or
is it a kernel only problem?
> --
> Xi Ruoyao
> School of Aerospace Science and Technology, Xidian University
>
--
You have seen "Linux from scratch" and looking for ISO files
www.osukiss.org
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On 2021-02-10 22:47 +0100, Pierre Labastie wrote:
> On Wed, 2021-02-10 at 21:03 +, Ken Moffat wrote:
> > On Wed, Feb 10, 2021 at 08:49:56PM +, Ken Moffat wrote:
> > > >
> > > > Looks like I need to change the Frame pointer unwinder to the
> > > > ORC unwinder to have the same config as you.
> > > >
> > >
> > > The benefits of the ORC unwinder are mentioned at
> > > https://www.kernel.org/doc/html/latest/x86/orc-unwinder.html
> > >
> > > It has been around for quite some time, but I probably picked it
> > > up when it first appeared (test an -rc kernel, pick up new options
> > > which might be useful). I guess that old configs from before its
> > > introduction still default to the old unwinder.
> > >
> > In fact it caused trouble about 3 years ago, there are links to the
> > -dev archive from around January 2018 when elfutils was still in
> > BLFS, and at that time LFS had to use the frame pointer. So when
> > libelf arrived in LFS I started to use it (or use it again, not sure
> > which).
> >
>
> I managed to compile objtool with -g, to recompile apic.c to apic.o
> (because it gets erased when objtool fails), and to run the objtool
> command on it under gdb. The segfault is esay to understand:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00412f71 in elf_rebuild_rela_reloc_section (sec=0xe22b10,
> nr=16)
> at elf.c:883
> 883 relocs[idx].r_info = GELF_R_INFO(reloc->sym-
> > idx, reloc->type);
>
> and the reloc struct is:
> (gdb) p *reloc
> $2 = {list = {next = 0xe23240, prev = 0xe23160}, hash = {next = 0x0,
> pprev = 0xe23250}, {rela = {r_offset = 0, r_info = 0, r_addend =
> 0},
> rel = {r_offset = 0, r_info = 0}}, sec = 0xe22b10, sym = 0x0,
> offset = 48,
> type = 2, addend = 467, idx = 0, jump_table_start = false}
>
> So reloc->sym is zero, and reloc->sym->idx is a null dereference...
>
> Now to understand why reloc->sym is zero is more complicated...
I can reproduce it too with Ken's config and just "make
arch/x86/kernel/apic/apic.o".
I seen a strange warning in build:
> Warning: Kernel ABI header at 'tools/arch/x86/lib/insn.c' differs from latest
> version at 'arch/x86/lib/insn.c'
Not sure if it causes the segfault. I'll try 5.10.15 and if it's not fixed I'll
report it as a kernel bug.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On Wed, Feb 10, 2021 at 08:49:56PM +, Ken Moffat wrote: > > > > Looks like I need to change the Frame pointer unwinder to the > > ORC unwinder to have the same config as you. > > > > The benefits of the ORC unwinder are mentioned at > https://www.kernel.org/doc/html/latest/x86/orc-unwinder.html > > It has been around for quite some time, but I probably picked it > up when it first appeared (test an -rc kernel, pick up new options > which might be useful). I guess that old configs from before its > introduction still default to the old unwinder. > In fact it caused trouble about 3 years ago, there are links to the -dev archive from around January 2018 when elfutils was still in BLFS, and at that time LFS had to use the frame pointer. So when libelf arrived in LFS I started to use it (or use it again, not sure which). ĸen -- Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout. -- rfc 2324 (1st April 1998) -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On Wed, Feb 10, 2021 at 09:39:20PM +0100, Pierre Labastie wrote: > On Wed, 2021-02-10 at 16:32 +, Ken Moffat wrote: > > On Wed, Feb 10, 2021 at 10:44:31AM +0100, Pierre Labastie wrote: > > > On Tue, 2021-02-09 at 17:14 -0500, Jean-Marc Pigeon wrote: > > > > > > Since you two are the only ones (among the persons on this list, up > > > to > > > now) who see this, I guess it has something to do with either: > > > - an option in the config, that you use and the others don't > > > - some CFLAGS settings, but I doubt it, because the kernel build > > > system > > > resets them > > > > > > > > > > > > > > > > > > > Feb 8 20:45:13 leshp klogd: [62379.838193] objtool[10870]: > > > > > > segfault at 70 ip 0040c13e sp 7ffd0f655670 error > > > > > > 4 in > > > > > > objtool[402000+11000] > > > > > > followed by a dump of the code bytes. > > > > > > objtool is a kernel thing. According to > > > tools/objtool/Documentation/stack-validation.txt, > > > " > > > The kernel CONFIG_STACK_VALIDATION option enables a host tool named > > > objtool which runs at compile time. It has a "check" subcommand > > > which > > > analyzes every .o file and ensures the validity of its stack > > > metadata. > > > It enforces a set of rules on asm code and C inline assembly code > > > so > > > that stack traces can be reliable. > > > " > > > > > > Note that I do have that option set to y, but maybe other options > > > in > > > the "Compile-time checks and compiler options" may differ... > > > > > > rebuilding with "make V=1", I see that objtool is run after each > > > compilation. It might be interesting to compare the options that > > > are > > > passed to objtool in my case and in yours. Mine has: > > > ./tools/objtool/objtool check --retpoline --uaccess \ > > > arch/x86/kernel/apic/apic.o > > > > > > (same options for any object file, but I show the one that might be > > > faulty in your case). > > > > > > Maybe "gdb objtool" would allow to learn more (but may need to > > > recompile objtool with debug enabled, I'm not sure how to do that) > > > > > > Pierre > > > > > > > Hi all, > > > > I've gone back to my skylake and attempted a fresh build of 5.10.14. > > I used KBUILD_VERBOSE=1, for objtool I have: > > > > ./tools/objtool/objtool orc generate --no-fp --retpoline --uaccess \ > > arch/x86/kernel/apic/apic.o > > > > Note that the segfault seems to be happening *before* what you quote > > above (in generate, check presumably comes after that). > > > > The full command leading up to the error (not reformatted, > > everything between gcc and apic.c is one line): > > > > make -f ./scripts/Makefile.build obj=arch/x86/kernel/apic \ > > \ > > need-builtin=1 \ > > need-modorder=1 > > gcc -Wp,-MMD,arch/x86/kernel/apic/.apic.o.d -nostdinc -isystem > > /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.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 -include ./include/linux/compiler_types.h > > -D__KERNEL__ -fmacro-prefix-map=./= -Wall -Wundef > > -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing > > -fno-common -fshort-wchar -fno-PIE > > -Werror=implicit-function-declaration -Werror=implicit-int > > -Werror=return-type -Wno-format-security -std=gnu89 -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 -march=core2 > > -mno-red-zone -mcmodel=kernel -DCONFIG_X86_X32_ABI -Wno-sign-compare > > -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern > > -mindirect-branch-register -fno-jump-tables > > -fno-delete-null-pointer-checks -Wno-frame-address > > -Wno-format-truncation -Wno-format-overflow > > -Wno-address-of-packed-member -O2 -fno-allow-store-data-races > > -Wframe-larger-than=2048 -fstack-protector-strong > > -Wno-unused-but-set-variable -Wimplicit-fallthrough > > -Wno-unused-const-variable -pg -mrecord-mcount -mfentry > > -DCC_USING_FENTRY -Wdeclaration-after-statement -Wvla > > -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds > > -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict > > -Wno-maybe-uninitialized -fno-strict-overflow -fno-stack-check > > -fconserve-stack -Werror=date-time > > -Werror=incompatible-pointer-types -Werror=designated-init > > -fcf-protection=none -Wno-packed-not-aligned > > -fplugin=./scripts/gcc-plugins/latent_entropy_plugin.so > > -fplugin=./scripts/gcc-plugins/structleak_plugin.so > > -fplugin=./scripts/gcc-plugins/randomize_layout_plugin.so > > -DLATENT_ENTROPY_PLUGIN -fplugin-arg-structleak_plugin-byref-all > > -DSTRUCTLEAK_PLUGIN -DRANDSTRUCT_PLUGIN > > -fplugin-arg-randomize_layout_plugin-performance-mode > > -DKBUILD_MODFILE='"arch/x86/kernel/apic/apic"' > > -DKBUILD_BASENAME='"apic"' -DKBUILD_MODNAME='"apic"' -c -o > >
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On Wed, 2021-02-10 at 21:03 +, Ken Moffat wrote:
> On Wed, Feb 10, 2021 at 08:49:56PM +, Ken Moffat wrote:
> > >
> > > Looks like I need to change the Frame pointer unwinder to the
> > > ORC unwinder to have the same config as you.
> > >
> >
> > The benefits of the ORC unwinder are mentioned at
> > https://www.kernel.org/doc/html/latest/x86/orc-unwinder.html
> >
> > It has been around for quite some time, but I probably picked it
> > up when it first appeared (test an -rc kernel, pick up new options
> > which might be useful). I guess that old configs from before its
> > introduction still default to the old unwinder.
> >
> In fact it caused trouble about 3 years ago, there are links to the
> -dev archive from around January 2018 when elfutils was still in
> BLFS, and at that time LFS had to use the frame pointer. So when
> libelf arrived in LFS I started to use it (or use it again, not sure
> which).
>
I managed to compile objtool with -g, to recompile apic.c to apic.o
(because it gets erased when objtool fails), and to run the objtool
command on it under gdb. The segfault is esay to understand:
Program received signal SIGSEGV, Segmentation fault.
0x00412f71 in elf_rebuild_rela_reloc_section (sec=0xe22b10,
nr=16)
at elf.c:883
883 relocs[idx].r_info = GELF_R_INFO(reloc->sym-
>idx, reloc->type);
and the reloc struct is:
(gdb) p *reloc
$2 = {list = {next = 0xe23240, prev = 0xe23160}, hash = {next = 0x0,
pprev = 0xe23250}, {rela = {r_offset = 0, r_info = 0, r_addend =
0},
rel = {r_offset = 0, r_info = 0}}, sec = 0xe22b10, sym = 0x0,
offset = 48,
type = 2, addend = 467, idx = 0, jump_table_start = false}
So reloc->sym is zero, and reloc->sym->idx is a null dereference...
Now to understand why reloc->sym is zero is more complicated...
Pierre
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On Wed, Feb 10, 2021 at 10:44:31AM +0100, Pierre Labastie wrote: > On Tue, 2021-02-09 at 17:14 -0500, Jean-Marc Pigeon wrote: > > Hello, > > On Tue, 2021-02-09 at 18:27 +, Ken Moffat wrote: > > > On Tue, Feb 09, 2021 at 12:29:14AM +, Ken Moffat wrote: > > > > On Mon, Feb 08, 2021 at 03:52:35AM +, Ken Moffat wrote: > > > > > > > > > > ../configure --prefix=/usr \ > > > > > --disable-werror \ > > > > > --enable-kernel=3.2 \ > > > > > --enable-stack-protector=strong \ > > > > > --with-headers=/usr/include \ > > > > > libc_cv_slibdir=/lib > > > > > libc_cv_include_x86_isa_level=no > > > > > > > > > > I've started the native build, but the machine is slow (i3, > > > > > slow > > > > > DRAM) and I'm not sure it will get very far before I go to > > > > > bed. > > > > > My > > > > > revised plan is to wait for it to fail, whether that is failign > > > > > the > > > > > build or failing to boot. > > > > > > > > > > Assuming it does fail, I'll start again with that workaround. > > > > > > > > > Well I don't need that workaround for using '-march=native -O2' > > > > on > > > > my skylake, it booted successfully. Fortunately, Frans said it > > > > works for him, and htat distros are using it, so I guess we too > > > > should use it. > > > > > > > > However, there was one problem other than my own typos in editing > > > > scripts - tried to build linux-5.10.13 - > > > > > > > > CC arch/x86/kernel/apic/apic.o > > > > make[3]: *** [scripts/Makefile.build:279: > > > > arch/x86/kernel/apic/apic.o] Segmentation fault > > Exact same problem here (not a memory problem, or very big > > "cosmic ray"). same problem on kernel-5.10.9 too. > > this happen using glibc-2.33 AND binutils-2.36.1 > > > > rebuilding from scratch using binutils-2.36.1 and keeping > > glibc-2.32 make the segmentation fault (I previously restarted > > build from scratch with glibc-2.32 + binutils-2.35.1, kernel > > compilation was OK). > > My conclusion, binutils is the trouble maker. > > Could somebody confirm this finding? > > Google is mute on this subject but may be my search > > keywords were not that good. > > advices? suggestions? > > Since you two are the only ones (among the persons on this list, up to > now) who see this, I guess it has something to do with either: > - an option in the config, that you use and the others don't > - some CFLAGS settings, but I doubt it, because the kernel build system > resets them > > > > > > > > > > > Feb 8 20:45:13 leshp klogd: [62379.838193] objtool[10870]: > > > > segfault at 70 ip 0040c13e sp 7ffd0f655670 error 4 in > > > > objtool[402000+11000] > > > > followed by a dump of the code bytes. > > objtool is a kernel thing. According to > tools/objtool/Documentation/stack-validation.txt, > " > The kernel CONFIG_STACK_VALIDATION option enables a host tool named > objtool which runs at compile time. It has a "check" subcommand which > analyzes every .o file and ensures the validity of its stack metadata. > It enforces a set of rules on asm code and C inline assembly code so > that stack traces can be reliable. > " > > Note that I do have that option set to y, but maybe other options in > the "Compile-time checks and compiler options" may differ... > > rebuilding with "make V=1", I see that objtool is run after each > compilation. It might be interesting to compare the options that are > passed to objtool in my case and in yours. Mine has: > ./tools/objtool/objtool check --retpoline --uaccess \ > arch/x86/kernel/apic/apic.o > > (same options for any object file, but I show the one that might be > faulty in your case). > > Maybe "gdb objtool" would allow to learn more (but may need to > recompile objtool with debug enabled, I'm not sure how to do that) > > Pierre > Hi all, I've gone back to my skylake and attempted a fresh build of 5.10.14. I used KBUILD_VERBOSE=1, for objtool I have: ./tools/objtool/objtool orc generate --no-fp --retpoline --uaccess \ arch/x86/kernel/apic/apic.o Note that the segfault seems to be happening *before* what you quote above (in generate, check presumably comes after that). The full command leading up to the error (not reformatted, everything between gcc and apic.c is one line): make -f ./scripts/Makefile.build obj=arch/x86/kernel/apic \ \ need-builtin=1 \ need-modorder=1 gcc -Wp,-MMD,arch/x86/kernel/apic/.apic.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.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 -include ./include/linux/compiler_types.h -D__KERNEL__ -fmacro-prefix-map=./= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On Wed, 2021-02-10 at 16:32 +, Ken Moffat wrote: > On Wed, Feb 10, 2021 at 10:44:31AM +0100, Pierre Labastie wrote: > > On Tue, 2021-02-09 at 17:14 -0500, Jean-Marc Pigeon wrote: > > > Hello, > > > On Tue, 2021-02-09 at 18:27 +, Ken Moffat wrote: > > > > On Tue, Feb 09, 2021 at 12:29:14AM +, Ken Moffat wrote: > > > > > On Mon, Feb 08, 2021 at 03:52:35AM +, Ken Moffat wrote: > > > > > > > > > > > > ../configure --prefix=/usr \ > > > > > > --disable-werror \ > > > > > > --enable-kernel=3.2 \ > > > > > > --enable-stack-protector=strong \ > > > > > > --with-headers=/usr/include \ > > > > > > libc_cv_slibdir=/lib > > > > > > libc_cv_include_x86_isa_level=no > > > > > > > > > > > > I've started the native build, but the machine is slow (i3, > > > > > > slow > > > > > > DRAM) and I'm not sure it will get very far before I go to > > > > > > bed. > > > > > > My > > > > > > revised plan is to wait for it to fail, whether that is > > > > > > failign > > > > > > the > > > > > > build or failing to boot. > > > > > > > > > > > > Assuming it does fail, I'll start again with that > > > > > > workaround. > > > > > > > > > > > Well I don't need that workaround for using '-march=native - > > > > > O2' > > > > > on > > > > > my skylake, it booted successfully. Fortunately, Frans said > > > > > it > > > > > works for him, and htat distros are using it, so I guess we > > > > > too > > > > > should use it. > > > > > > > > > > However, there was one problem other than my own typos in > > > > > editing > > > > > scripts - tried to build linux-5.10.13 - > > > > > > > > > > CC arch/x86/kernel/apic/apic.o > > > > > make[3]: *** [scripts/Makefile.build:279: > > > > > arch/x86/kernel/apic/apic.o] Segmentation fault > > > Exact same problem here (not a memory problem, or very big > > > "cosmic ray"). same problem on kernel-5.10.9 too. > > > this happen using glibc-2.33 AND binutils-2.36.1 > > > > > > rebuilding from scratch using binutils-2.36.1 and keeping > > > glibc-2.32 make the segmentation fault (I previously restarted > > > build from scratch with glibc-2.32 + binutils-2.35.1, kernel > > > compilation was OK). > > > My conclusion, binutils is the trouble maker. > > > Could somebody confirm this finding? > > > Google is mute on this subject but may be my search > > > keywords were not that good. > > > advices? suggestions? > > > > Since you two are the only ones (among the persons on this list, up > > to > > now) who see this, I guess it has something to do with either: > > - an option in the config, that you use and the others don't > > - some CFLAGS settings, but I doubt it, because the kernel build > > system > > resets them > > > > > > > > > > > > > > > Feb 8 20:45:13 leshp klogd: [62379.838193] objtool[10870]: > > > > > segfault at 70 ip 0040c13e sp 7ffd0f655670 error > > > > > 4 in > > > > > objtool[402000+11000] > > > > > followed by a dump of the code bytes. > > > > objtool is a kernel thing. According to > > tools/objtool/Documentation/stack-validation.txt, > > " > > The kernel CONFIG_STACK_VALIDATION option enables a host tool named > > objtool which runs at compile time. It has a "check" subcommand > > which > > analyzes every .o file and ensures the validity of its stack > > metadata. > > It enforces a set of rules on asm code and C inline assembly code > > so > > that stack traces can be reliable. > > " > > > > Note that I do have that option set to y, but maybe other options > > in > > the "Compile-time checks and compiler options" may differ... > > > > rebuilding with "make V=1", I see that objtool is run after each > > compilation. It might be interesting to compare the options that > > are > > passed to objtool in my case and in yours. Mine has: > > ./tools/objtool/objtool check --retpoline --uaccess \ > > arch/x86/kernel/apic/apic.o > > > > (same options for any object file, but I show the one that might be > > faulty in your case). > > > > Maybe "gdb objtool" would allow to learn more (but may need to > > recompile objtool with debug enabled, I'm not sure how to do that) > > > > Pierre > > > > Hi all, > > I've gone back to my skylake and attempted a fresh build of 5.10.14. > I used KBUILD_VERBOSE=1, for objtool I have: > > ./tools/objtool/objtool orc generate --no-fp --retpoline --uaccess \ > arch/x86/kernel/apic/apic.o > > Note that the segfault seems to be happening *before* what you quote > above (in generate, check presumably comes after that). > > The full command leading up to the error (not reformatted, > everything between gcc and apic.c is one line): > > make -f ./scripts/Makefile.build obj=arch/x86/kernel/apic \ > \ > need-builtin=1 \ > need-modorder=1 > gcc -Wp,-MMD,arch/x86/kernel/apic/.apic.o.d -nostdinc -isystem > /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/include
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
Hello, On Wed, 2021-02-10 at 09:52 +0100, Frans de Boer wrote: > On 10/02/2021 02:49, Ken Moffat wrote: > > On Tue, Feb 09, 2021 at 05:14:09PM -0500, Jean-Marc Pigeon wrote: > > > Hello, > > > On Tue, 2021-02-09 at 18:27 +, Ken Moffat wrote: > > > > On Tue, Feb 09, 2021 at 12:29:14AM +, Ken Moffat wrote: > > > > > On Mon, Feb 08, 2021 at 03:52:35AM +, Ken Moffat wrote: > > > > > > ../configure --prefix=/usr \ > > > > > > --disable-werror \ > > > > > > --enable-kernel=3.2 \ > > > > > > --enable-stack-protector=strong \ > > > > > > --with-headers=/usr/include \ > > > > > > libc_cv_slibdir=/lib > > > > > > libc_cv_include_x86_isa_level=no > > > > > > > > [...] > > > > > Well I don't need that workaround for using '-march=native - > > > > > O2' on > > > > > my skylake, it booted successfully. Fortunately, Frans said > > > > > it > > > > > works for him, and htat distros are using it, so I guess we > > > > > too > > > > > should use it. > > > > > > > > > > However, there was one problem other than my own typos in > > > > > editing > > > > > scripts - tried to build linux-5.10.13 - > > > > > > > > > > CC arch/x86/kernel/apic/apic.o > > > > > make[3]: *** [scripts/Makefile.build:279: > > > > > arch/x86/kernel/apic/apic.o] Segmentation fault > > > Exact same problem here (not a memory problem, or very big > > > "cosmic ray"). same problem on kernel-5.10.9 too. > > > this happen using glibc-2.33 AND binutils-2.36.1 > > > > > > rebuilding from scratch using binutils-2.36.1 and keeping > > > glibc-2.32 make the segmentation fault (I previously restarted > > > build from scratch with glibc-2.32 + binutils-2.35.1, kernel > > > compilation was OK). > > > My conclusion, binutils is the trouble maker. > > > Could somebody confirm this finding? > > > Google is mute on this subject but may be my search > > > keywords were not that good. > > > advices? suggestions? > > > > > Wow! I hadn't thought of trying binutils-2.36.1 with glibc-2.32 > > (partly because I'd prefer to use glibc-2.33 because of its iconv > > fixes). > > > > And I'm surprised at 5.10.9 because based on the kernel list and > > binutils-bugs I had thought that would crap out in objcopy (with an > > error message about the sections, not a segfault). > > > > This does sound as if it is a real problem, but I guess the reason > > google is not coming up with anything is that binutils-2.36 and > > 2.36.1 are fresh. Normally we try to keep on the cutting edge > > rather than the bleeding edge, but this time we've maybe overshot. > > > > Just to be clear (before Bruce asks, I know he distrusts using any > > CFLAGS) - are you building with any variant of -march= ? And what > > CPU are you building on ? Intel(R) Core(TM) i7 CPU 970 @ 3.20GH all compilation done within a / tmpfs 40G Recompilation is done in 2 phases, first the tool-chain (automatic make sequence) then recompile everything within the previously builded tool-chain building process is all "all automatic" (> 1000 utilities/tools/applications) duration is around 5 hours. Here is my finding (everything equal beside the glibc binutils version (kernel-5.10.13)) glibc binutils 2.32 2.35.1 compilation successful all the way 2.33 2.36.1 compilation stop at kernel (segmentation fault) kernel is among the last components to be build 2.33 2.35.1 webkitgtk (2.30.4) compilation error, compilation sequence make webkitgtk to be compiled before kernel. (but manual request to compile kernel is successful) 2.32 2.36.1 segmentation fault on kernel compilation (manual request) Manual request about kernel, mean I didn't wait for all packages to be compiled but building context is good enough to have kernel compilation to be successful. At first, I beleived only binutils-2.36.1 was the problem, seems interaction between glibc+binutils are subtle. IMHO: at that stage, modification done to low level components as glibc, binutils should be transparent to a (proved working) building process. So we have; my bet; something fishy, hidden somewhere within both glibc and binutils. could someone else confirm my data with its own experiment? > > I'm still not ready to start my next build, but suddenly I'm even > > less looking forward to it :) > > > > If this is a common problem, I would have though Bruce would have > > seen it when he updated to 2.36 and 2.36.1 - so I assume there is > > some other factor which is not yet obvious. > > > > ĸen > I have rebuild the SysVinit as well as the Systemd version from the > dev > version plus the additional libc... flag for glibc as well as the > extra > flag for binutils. > I had problems before, but after removing the stale CFLAGS variable, > I > could compile everything and successfully booted the resulting images > on > my older but still
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On Tue, 2021-02-09 at 17:14 -0500, Jean-Marc Pigeon wrote: > Hello, > On Tue, 2021-02-09 at 18:27 +, Ken Moffat wrote: > > On Tue, Feb 09, 2021 at 12:29:14AM +, Ken Moffat wrote: > > > On Mon, Feb 08, 2021 at 03:52:35AM +, Ken Moffat wrote: > > > > > > > > ../configure --prefix=/usr \ > > > > --disable-werror \ > > > > --enable-kernel=3.2 \ > > > > --enable-stack-protector=strong \ > > > > --with-headers=/usr/include \ > > > > libc_cv_slibdir=/lib > > > > libc_cv_include_x86_isa_level=no > > > > > > > > I've started the native build, but the machine is slow (i3, > > > > slow > > > > DRAM) and I'm not sure it will get very far before I go to > > > > bed. > > > > My > > > > revised plan is to wait for it to fail, whether that is failign > > > > the > > > > build or failing to boot. > > > > > > > > Assuming it does fail, I'll start again with that workaround. > > > > > > > Well I don't need that workaround for using '-march=native -O2' > > > on > > > my skylake, it booted successfully. Fortunately, Frans said it > > > works for him, and htat distros are using it, so I guess we too > > > should use it. > > > > > > However, there was one problem other than my own typos in editing > > > scripts - tried to build linux-5.10.13 - > > > > > > CC arch/x86/kernel/apic/apic.o > > > make[3]: *** [scripts/Makefile.build:279: > > > arch/x86/kernel/apic/apic.o] Segmentation fault > Exact same problem here (not a memory problem, or very big > "cosmic ray"). same problem on kernel-5.10.9 too. > this happen using glibc-2.33 AND binutils-2.36.1 > > rebuilding from scratch using binutils-2.36.1 and keeping > glibc-2.32 make the segmentation fault (I previously restarted > build from scratch with glibc-2.32 + binutils-2.35.1, kernel > compilation was OK). > My conclusion, binutils is the trouble maker. > Could somebody confirm this finding? > Google is mute on this subject but may be my search > keywords were not that good. > advices? suggestions? Since you two are the only ones (among the persons on this list, up to now) who see this, I guess it has something to do with either: - an option in the config, that you use and the others don't - some CFLAGS settings, but I doubt it, because the kernel build system resets them > > > > > > > Feb 8 20:45:13 leshp klogd: [62379.838193] objtool[10870]: > > > segfault at 70 ip 0040c13e sp 7ffd0f655670 error 4 in > > > objtool[402000+11000] > > > followed by a dump of the code bytes. objtool is a kernel thing. According to tools/objtool/Documentation/stack-validation.txt, " The kernel CONFIG_STACK_VALIDATION option enables a host tool named objtool which runs at compile time. It has a "check" subcommand which analyzes every .o file and ensures the validity of its stack metadata. It enforces a set of rules on asm code and C inline assembly code so that stack traces can be reliable. " Note that I do have that option set to y, but maybe other options in the "Compile-time checks and compiler options" may differ... rebuilding with "make V=1", I see that objtool is run after each compilation. It might be interesting to compare the options that are passed to objtool in my case and in yours. Mine has: ./tools/objtool/objtool check --retpoline --uaccess \ arch/x86/kernel/apic/apic.o (same options for any object file, but I show the one that might be faulty in your case). Maybe "gdb objtool" would allow to learn more (but may need to recompile objtool with debug enabled, I'm not sure how to do that) Pierre -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On 10/02/2021 02:49, Ken Moffat wrote: On Tue, Feb 09, 2021 at 05:14:09PM -0500, Jean-Marc Pigeon wrote: Hello, On Tue, 2021-02-09 at 18:27 +, Ken Moffat wrote: On Tue, Feb 09, 2021 at 12:29:14AM +, Ken Moffat wrote: On Mon, Feb 08, 2021 at 03:52:35AM +, Ken Moffat wrote: ../configure --prefix=/usr \ --disable-werror \ --enable-kernel=3.2 \ --enable-stack-protector=strong \ --with-headers=/usr/include \ libc_cv_slibdir=/lib libc_cv_include_x86_isa_level=no [...] Well I don't need that workaround for using '-march=native -O2' on my skylake, it booted successfully. Fortunately, Frans said it works for him, and htat distros are using it, so I guess we too should use it. However, there was one problem other than my own typos in editing scripts - tried to build linux-5.10.13 - CC arch/x86/kernel/apic/apic.o make[3]: *** [scripts/Makefile.build:279: arch/x86/kernel/apic/apic.o] Segmentation fault Exact same problem here (not a memory problem, or very big "cosmic ray"). same problem on kernel-5.10.9 too. this happen using glibc-2.33 AND binutils-2.36.1 rebuilding from scratch using binutils-2.36.1 and keeping glibc-2.32 make the segmentation fault (I previously restarted build from scratch with glibc-2.32 + binutils-2.35.1, kernel compilation was OK). My conclusion, binutils is the trouble maker. Could somebody confirm this finding? Google is mute on this subject but may be my search keywords were not that good. advices? suggestions? Wow! I hadn't thought of trying binutils-2.36.1 with glibc-2.32 (partly because I'd prefer to use glibc-2.33 because of its iconv fixes). And I'm surprised at 5.10.9 because based on the kernel list and binutils-bugs I had thought that would crap out in objcopy (with an error message about the sections, not a segfault). This does sound as if it is a real problem, but I guess the reason google is not coming up with anything is that binutils-2.36 and 2.36.1 are fresh. Normally we try to keep on the cutting edge rather than the bleeding edge, but this time we've maybe overshot. Just to be clear (before Bruce asks, I know he distrusts using any CFLAGS) - are you building with any variant of -march= ? And what CPU are you building on ? I'm still not ready to start my next build, but suddenly I'm even less looking forward to it :) If this is a common problem, I would have though Bruce would have seen it when he updated to 2.36 and 2.36.1 - so I assume there is some other factor which is not yet obvious. ĸen I have rebuild the SysVinit as well as the Systemd version from the dev version plus the additional libc... flag for glibc as well as the extra flag for binutils. I had problems before, but after removing the stale CFLAGS variable, I could compile everything and successfully booted the resulting images on my older but still capable Phenom II based system. Same at an older XEON system. --- Frans. -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
On Tue, Feb 09, 2021 at 05:14:09PM -0500, Jean-Marc Pigeon wrote: > Hello, > On Tue, 2021-02-09 at 18:27 +, Ken Moffat wrote: > > On Tue, Feb 09, 2021 at 12:29:14AM +, Ken Moffat wrote: > > > On Mon, Feb 08, 2021 at 03:52:35AM +, Ken Moffat wrote: > > > > > > > > ../configure --prefix=/usr \ > > > > --disable-werror \ > > > > --enable-kernel=3.2 \ > > > > --enable-stack-protector=strong \ > > > > --with-headers=/usr/include \ > > > > libc_cv_slibdir=/lib > > > > libc_cv_include_x86_isa_level=no > > > > [...] > > > Well I don't need that workaround for using '-march=native -O2' on > > > my skylake, it booted successfully. Fortunately, Frans said it > > > works for him, and htat distros are using it, so I guess we too > > > should use it. > > > > > > However, there was one problem other than my own typos in editing > > > scripts - tried to build linux-5.10.13 - > > > > > > CC arch/x86/kernel/apic/apic.o > > > make[3]: *** [scripts/Makefile.build:279: > > > arch/x86/kernel/apic/apic.o] Segmentation fault > Exact same problem here (not a memory problem, or very big > "cosmic ray"). same problem on kernel-5.10.9 too. > this happen using glibc-2.33 AND binutils-2.36.1 > > rebuilding from scratch using binutils-2.36.1 and keeping > glibc-2.32 make the segmentation fault (I previously restarted > build from scratch with glibc-2.32 + binutils-2.35.1, kernel > compilation was OK). > My conclusion, binutils is the trouble maker. > Could somebody confirm this finding? > Google is mute on this subject but may be my search > keywords were not that good. > advices? suggestions? > Wow! I hadn't thought of trying binutils-2.36.1 with glibc-2.32 (partly because I'd prefer to use glibc-2.33 because of its iconv fixes). And I'm surprised at 5.10.9 because based on the kernel list and binutils-bugs I had thought that would crap out in objcopy (with an error message about the sections, not a segfault). This does sound as if it is a real problem, but I guess the reason google is not coming up with anything is that binutils-2.36 and 2.36.1 are fresh. Normally we try to keep on the cutting edge rather than the bleeding edge, but this time we've maybe overshot. Just to be clear (before Bruce asks, I know he distrusts using any CFLAGS) - are you building with any variant of -march= ? And what CPU are you building on ? I'm still not ready to start my next build, but suddenly I'm even less looking forward to it :) If this is a common problem, I would have though Bruce would have seen it when he updated to 2.36 and 2.36.1 - so I assume there is some other factor which is not yet obvious. ĸen -- Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout. -- rfc 2324 (1st April 1998) -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Compile error glibc2.33 -> binutils-2.36.1
Hello, On Tue, 2021-02-09 at 18:27 +, Ken Moffat wrote: > On Tue, Feb 09, 2021 at 12:29:14AM +, Ken Moffat wrote: > > On Mon, Feb 08, 2021 at 03:52:35AM +, Ken Moffat wrote: > > > > > > ../configure --prefix=/usr \ > > > --disable-werror \ > > > --enable-kernel=3.2 \ > > > --enable-stack-protector=strong \ > > > --with-headers=/usr/include \ > > > libc_cv_slibdir=/lib > > > libc_cv_include_x86_isa_level=no > > > > > > I've started the native build, but the machine is slow (i3, slow > > > DRAM) and I'm not sure it will get very far before I go to bed. > > > My > > > revised plan is to wait for it to fail, whether that is failign > > > the > > > build or failing to boot. > > > > > > Assuming it does fail, I'll start again with that workaround. > > > > > Well I don't need that workaround for using '-march=native -O2' on > > my skylake, it booted successfully. Fortunately, Frans said it > > works for him, and htat distros are using it, so I guess we too > > should use it. > > > > However, there was one problem other than my own typos in editing > > scripts - tried to build linux-5.10.13 - > > > > CC arch/x86/kernel/apic/apic.o > > make[3]: *** [scripts/Makefile.build:279: > > arch/x86/kernel/apic/apic.o] Segmentation fault Exact same problem here (not a memory problem, or very big "cosmic ray"). same problem on kernel-5.10.9 too. this happen using glibc-2.33 AND binutils-2.36.1 rebuilding from scratch using binutils-2.36.1 and keeping glibc-2.32 make the segmentation fault (I previously restarted build from scratch with glibc-2.32 + binutils-2.35.1, kernel compilation was OK). My conclusion, binutils is the trouble maker. Could somebody confirm this finding? Google is mute on this subject but may be my search keywords were not that good. advices? suggestions? > > > > Feb 8 20:45:13 leshp klogd: [62379.838193] objtool[10870]: > > segfault at 70 ip 0040c13e sp 7ffd0f655670 error 4 in > > objtool[402000+11000] > > followed by a dump of the code bytes. > > > > Decided to try 5.10.14 just in case, but that failed the same way, > > on the same file (freshly extracted 5.10 source, freshly patched to > > .14). Then I tried 5.11.0-rc7 and that built without problems. > > > > My initial guess is that the memory has gone faulty, so I booted > > memtest86. That is currently part-way through the second of four > > passes, no errors found so far. Maybe it was the old "cosmic rays" > > problem, maybe an error will show before memtest86 finishes, or > > maybe binutils-2.36.1 still has a problem with something in the > > kernel. > > > > I suppose I'd better go back to updating the rest of my scripts so > > that I can try builds on haswell and zen1 with -march=native.+ > > > > Left memtest86 running, all tests ok, but then I noticed it had only > used one core (the default). Went back to the CPU options, but both > parrallel (all cores) and round robin quickly reported that UEFI had > failed to start CPU2. My LFS systems on hat machine use the bios, I > suspect the UEFI problem is par for the course on lower-end > machines from that date. > > I then booted the new svn system again (5.11.0-rc7) and tried to > build 5.10.13, 5.10.12, 5.10.15-rc1 : all again failed with a > segfault. I'll give it another try with the extra libc_cv setting > just in case, but probably not for a few days. > > First, I'm running memtest86 on my oldest ryzen before trying to > build that with -march=native -O3 (again, without the additional > libc_cv). > > ĸen > -- > Any attempt to brew coffee with a teapot should result in the error > code "418 I'm a teapot". The resulting entity body MAY be short and > stout. -- rfc 2324 (1st April 1998) > -- You have seen "Linux from scratch" and looking for ISO files www.osukiss.org -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
