Hi all,
The latest GNU assembler (binutils-2.36.1) is removing unused section symbols
like Clang [1]. So linux-5.10.15 can't be built with binutils-2.36.1 now. It
has been reported as https://bugzilla.kernel.org/show_bug.cgi?id=211693.
I can confirm this commit fixes the issue. It should be cherry-picked into
stable branches, so the following stable releases will be able to built with
latest GNU toolchain.
[1]: https://sourceware.org/pipermail/binutils/2020-December/114671.html
At last, happy new lunar year guys :).
On 2020-12-16 13:49 +0000, tip-bot2 for Josh Poimboeuf wrote:
> The following commit has been merged into the objtool/urgent branch of tip:
>
> Commit-ID: 44f6a7c0755d8dd453c70557e11687bb080a6f21
> Gitweb:
> https://git.kernel.org/tip/44f6a7c0755d8dd453c70557e11687bb080a6f21
> Author: Josh Poimboeuf <[email protected]>
> AuthorDate: Mon, 14 Dec 2020 16:04:20 -06:00
> Committer: Peter Zijlstra <[email protected]>
> CommitterDate: Wed, 16 Dec 2020 14:35:46 +01:00
>
> objtool: Fix seg fault with Clang non-section symbols
>
> The Clang assembler likes to strip section symbols, which means objtool
> can't reference some text code by its section. This confuses objtool
> greatly, causing it to seg fault.
>
> The fix is similar to what was done before, for ORC reloc generation:
>
> e81e07244325 ("objtool: Support Clang non-section symbols in ORC
> generation")
>
> Factor out that code into a common helper and use it for static call
> reloc generation as well.
>
> Reported-by: Arnd Bergmann <[email protected]>
> Signed-off-by: Josh Poimboeuf <[email protected]>
> Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
> Reviewed-by: Nick Desaulniers <[email protected]>
> Reviewed-by: Miroslav Benes <[email protected]>
> Link: https://github.com/ClangBuiltLinux/linux/issues/1207
> Link:
> https://lkml.kernel.org/r/ba6b6c0f0dd5acbba66e403955a967d9fdd1726a.1607983452.git.jpoimboe@redhat.com
> ---
> tools/objtool/check.c | 11 +++++++++--
> tools/objtool/elf.c | 26 ++++++++++++++++++++++++++
> tools/objtool/elf.h | 2 ++
> tools/objtool/orc_gen.c | 29 +++++------------------------
> 4 files changed, 42 insertions(+), 26 deletions(-)
>
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index c6ab445..5f8d3ee 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -467,13 +467,20 @@ static int create_static_call_sections(struct
> objtool_file *file)
>
> /* populate reloc for 'addr' */
> reloc = malloc(sizeof(*reloc));
> +
> if (!reloc) {
> perror("malloc");
> return -1;
> }
> memset(reloc, 0, sizeof(*reloc));
> - reloc->sym = insn->sec->sym;
> - reloc->addend = insn->offset;
> +
> + insn_to_reloc_sym_addend(insn->sec, insn->offset, reloc);
> + if (!reloc->sym) {
> + WARN_FUNC("static call tramp: missing containing
> symbol",
> + insn->sec, insn->offset);
> + return -1;
> + }
> +
> reloc->type = R_X86_64_PC32;
> reloc->offset = idx * sizeof(struct static_call_site);
> reloc->sec = reloc_sec;
> diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
> index 4e1d746..be89c74 100644
> --- a/tools/objtool/elf.c
> +++ b/tools/objtool/elf.c
> @@ -262,6 +262,32 @@ struct reloc *find_reloc_by_dest(const struct elf *elf,
> struct section *sec, uns
> return find_reloc_by_dest_range(elf, sec, offset, 1);
> }
>
> +void insn_to_reloc_sym_addend(struct section *sec, unsigned long offset,
> + struct reloc *reloc)
> +{
> + if (sec->sym) {
> + reloc->sym = sec->sym;
> + reloc->addend = offset;
> + return;
> + }
> +
> + /*
> + * The Clang assembler strips section symbols, so we have to reference
> + * the function symbol instead:
> + */
> + reloc->sym = find_symbol_containing(sec, offset);
> + if (!reloc->sym) {
> + /*
> + * Hack alert. This happens when we need to reference the NOP
> + * pad insn immediately after the function.
> + */
> + reloc->sym = find_symbol_containing(sec, offset - 1);
> + }
> +
> + if (reloc->sym)
> + reloc->addend = offset - reloc->sym->offset;
> +}
> +
> static int read_sections(struct elf *elf)
> {
> Elf_Scn *s = NULL;
> diff --git a/tools/objtool/elf.h b/tools/objtool/elf.h
> index 807f8c6..e6890cc 100644
> --- a/tools/objtool/elf.h
> +++ b/tools/objtool/elf.h
> @@ -140,6 +140,8 @@ struct reloc *find_reloc_by_dest(const struct elf *elf,
> struct section *sec, uns
> struct reloc *find_reloc_by_dest_range(const struct elf *elf, struct section
> *sec,
> unsigned long offset, unsigned int len);
> struct symbol *find_func_containing(struct section *sec, unsigned long
> offset);
> +void insn_to_reloc_sym_addend(struct section *sec, unsigned long offset,
> + struct reloc *reloc);
> int elf_rebuild_reloc_section(struct elf *elf, struct section *sec);
>
> #define for_each_sec(file,
> sec) \
> diff --git a/tools/objtool/orc_gen.c b/tools/objtool/orc_gen.c
> index 235663b..9ce68b3 100644
> --- a/tools/objtool/orc_gen.c
> +++ b/tools/objtool/orc_gen.c
> @@ -105,30 +105,11 @@ static int create_orc_entry(struct elf *elf, struct
> section *u_sec, struct secti
> }
> memset(reloc, 0, sizeof(*reloc));
>
> - if (insn_sec->sym) {
> - reloc->sym = insn_sec->sym;
> - reloc->addend = insn_off;
> - } else {
> - /*
> - * The Clang assembler doesn't produce section symbols, so we
> - * have to reference the function symbol instead:
> - */
> - reloc->sym = find_symbol_containing(insn_sec, insn_off);
> - if (!reloc->sym) {
> - /*
> - * Hack alert. This happens when we need to reference
> - * the NOP pad insn immediately after the function.
> - */
> - reloc->sym = find_symbol_containing(insn_sec,
> - insn_off - 1);
> - }
> - if (!reloc->sym) {
> - WARN("missing symbol for insn at offset 0x%lx\n",
> - insn_off);
> - return -1;
> - }
> -
> - reloc->addend = insn_off - reloc->sym->offset;
> + insn_to_reloc_sym_addend(insn_sec, insn_off, reloc);
> + if (!reloc->sym) {
> + WARN("missing symbol for insn at offset 0x%lx",
> + insn_off);
> + return -1;
> }
>
> reloc->type = R_X86_64_PC32;
--
Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University
On Thu, Feb 11, 2021 at 09:32:03PM +0800, Xi Ruoyao wrote:
> Hi all,
>
> The latest GNU assembler (binutils-2.36.1) is removing unused section symbols
> like Clang [1]. So linux-5.10.15 can't be built with binutils-2.36.1 now. It
> has been reported as https://bugzilla.kernel.org/show_bug.cgi?id=211693.
2.36 of binutils fails to build the 4.4.y tree right now as well, but as
objtool isn't there, I don't know what to do about it :(
thanks,
greg k-h
On Thu, Feb 11, 2021 at 5:55 AM Greg Kroah-Hartman
<[email protected]> wrote:
>
> On Thu, Feb 11, 2021 at 09:32:03PM +0800, Xi Ruoyao wrote:
> > Hi all,
> >
> > The latest GNU assembler (binutils-2.36.1) is removing unused section symbols
> > like Clang [1]. So linux-5.10.15 can't be built with binutils-2.36.1 now. It
> > has been reported as https://bugzilla.kernel.org/show_bug.cgi?id=211693.
Xi,
Happy Lunar New Year to you, too, and thanks for the report. Did you
observe such segfaults for older branches of stable?
> 2.36 of binutils fails to build the 4.4.y tree right now as well, but as
> objtool isn't there, I don't know what to do about it :(
Greg,
There may be multiple issues in the latest binutils release for the
kernel; we should still avoid segfaults in host tools so I do
recommend considering this patch for inclusion at least into 5.10.y.
Arnd's report in https://github.com/ClangBuiltLinux/linux/issues/1207
mentions this was found via randconfig testing, so likely some set of
configs is needed to reproduce reliably.
Do you have more info about the failure you're observing? Trolling
lore, I only see:
https://lore.kernel.org/stable/[email protected]/
(Maybe it was reported on a different list; I only searched stable ML).
--
Thanks,
~Nick Desaulniers
Hi Greg and Nick,
On 2021-02-11 10:46 -0800, Nick Desaulniers wrote:
> On Thu, Feb 11, 2021 at 5:55 AM Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > On Thu, Feb 11, 2021 at 09:32:03PM +0800, Xi Ruoyao wrote:
> > > Hi all,
> > >
> > > The latest GNU assembler (binutils-2.36.1) is removing unused section
> > > symbols
> > > like Clang [1]. So linux-5.10.15 can't be built with binutils-2.36.1
> > > now. It
> > > has been reported as https://bugzilla.kernel.org/show_bug.cgi?id=211693.
>
> Xi,
> Happy Lunar New Year to you, too, and thanks for the report. Did you
> observe such segfaults for older branches of stable?
We found this issue building Linux From Scratch
(http://www.linuxfromscratch.org/lfs/view/development/). We use the latest
stable kernel in the project so we have no report of older branches.
I tried 5.4.97 with a configuration "looks like" the one triggers the segfault
in 5.10.15. But 5.4.97 build does not segfault.
However, I guess for "some" config older branches may segfault too.
> > 2.36 of binutils fails to build the 4.4.y tree right now as well, but as
> > objtool isn't there, I don't know what to do about it :(
>
> Greg,
> There may be multiple issues in the latest binutils release for the
> kernel; we should still avoid segfaults in host tools so I do
> recommend considering this patch for inclusion at least into 5.10.y.
I strongly agree, or it may affect "rolling-release" distros (which are likely
to use binutils-2.36.1 and linux-5.10.y together) in an annoying way.
> Arnd's report in https://github.com/ClangBuiltLinux/linux/issues/1207
> mentions this was found via randconfig testing, so likely some set of
> configs is needed to reproduce reliably.
I attached a config in https://bugzilla.kernel.org/show_bug.cgi?id=211693 (also
attached in this mail). It reproduces the issue for 5.10.15 very reliably. At
least three of us tried this configuration on the system personally used (with
binutils-2.36.1) and we got exactly same error: objtool segfaults on apic.o.
> Do you have more info about the failure you're observing? Trolling
> lore, I only see:
> https://lore.kernel.org/stable/[email protected]/
> (Maybe it was reported on a different list; I only searched stable ML).
--
Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University
On Thu, Feb 11, 2021 at 10:46:05AM -0800, Nick Desaulniers wrote:
> On Thu, Feb 11, 2021 at 5:55 AM Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > On Thu, Feb 11, 2021 at 09:32:03PM +0800, Xi Ruoyao wrote:
> > > Hi all,
> > >
> > > The latest GNU assembler (binutils-2.36.1) is removing unused section symbols
> > > like Clang [1]. So linux-5.10.15 can't be built with binutils-2.36.1 now. It
> > > has been reported as https://bugzilla.kernel.org/show_bug.cgi?id=211693.
>
> Xi,
> Happy Lunar New Year to you, too, and thanks for the report. Did you
> observe such segfaults for older branches of stable?
>
> > 2.36 of binutils fails to build the 4.4.y tree right now as well, but as
> > objtool isn't there, I don't know what to do about it :(
>
> Greg,
> There may be multiple issues in the latest binutils release for the
> kernel; we should still avoid segfaults in host tools so I do
> recommend considering this patch for inclusion at least into 5.10.y.
> Arnd's report in https://github.com/ClangBuiltLinux/linux/issues/1207
> mentions this was found via randconfig testing, so likely some set of
> configs is needed to reproduce reliably.
>
> Do you have more info about the failure you're observing? Trolling
> lore, I only see:
> https://lore.kernel.org/stable/[email protected]/
> (Maybe it was reported on a different list; I only searched stable ML).
I didn't report it anywhere.
Here's the output of doing a 'make allmodconfig' on the latest 4.4.257
release failing with binutils 2.36
Cannot find symbol for section 8: .text.unlikely.
kernel/kexec_file.o: failed
make[1]: *** [scripts/Makefile.build:277: kernel/kexec_file.o] Error 1
make[1]: *** Deleting file 'kernel/kexec_file.o'
make[1]: *** Waiting for unfinished jobs....
4.9.257 works fine, probably because we are using objtool?
Any ideas are appreciated.
thanks,
greg k-h
On Fri, Feb 12, 2021 at 04:30:49PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Feb 11, 2021 at 10:46:05AM -0800, Nick Desaulniers wrote:
> > On Thu, Feb 11, 2021 at 5:55 AM Greg Kroah-Hartman
> > <[email protected]> wrote:
> > >
> > > On Thu, Feb 11, 2021 at 09:32:03PM +0800, Xi Ruoyao wrote:
> > > > Hi all,
> > > >
> > > > The latest GNU assembler (binutils-2.36.1) is removing unused section symbols
> > > > like Clang [1]. So linux-5.10.15 can't be built with binutils-2.36.1 now. It
> > > > has been reported as https://bugzilla.kernel.org/show_bug.cgi?id=211693.
> >
> > Xi,
> > Happy Lunar New Year to you, too, and thanks for the report. Did you
> > observe such segfaults for older branches of stable?
> >
> > > 2.36 of binutils fails to build the 4.4.y tree right now as well, but as
> > > objtool isn't there, I don't know what to do about it :(
> >
> > Greg,
> > There may be multiple issues in the latest binutils release for the
> > kernel; we should still avoid segfaults in host tools so I do
> > recommend considering this patch for inclusion at least into 5.10.y.
> > Arnd's report in https://github.com/ClangBuiltLinux/linux/issues/1207
> > mentions this was found via randconfig testing, so likely some set of
> > configs is needed to reproduce reliably.
> >
> > Do you have more info about the failure you're observing? Trolling
> > lore, I only see:
> > https://lore.kernel.org/stable/[email protected]/
> > (Maybe it was reported on a different list; I only searched stable ML).
>
> I didn't report it anywhere.
>
> Here's the output of doing a 'make allmodconfig' on the latest 4.4.257
> release failing with binutils 2.36
>
> Cannot find symbol for section 8: .text.unlikely.
> kernel/kexec_file.o: failed
> make[1]: *** [scripts/Makefile.build:277: kernel/kexec_file.o] Error 1
> make[1]: *** Deleting file 'kernel/kexec_file.o'
> make[1]: *** Waiting for unfinished jobs....
>
> 4.9.257 works fine, probably because we are using objtool?
>
> Any ideas are appreciated.
[ Adding Steve Rostedt ]
This error message comes from recordmcount. It probably can't handle
the missing STT_SECTION symbols which are getting stripped by the new
binutils. (Objtool also had trouble with that.)
No idea why you only see this on 4.4 though.
--
Josh
On Fri, 12 Feb 2021 11:07:50 -0600
Josh Poimboeuf <[email protected]> wrote:
> > Any ideas are appreciated.
>
> [ Adding Steve Rostedt ]
>
> This error message comes from recordmcount. It probably can't handle
> the missing STT_SECTION symbols which are getting stripped by the new
> binutils. (Objtool also had trouble with that.)
>
> No idea why you only see this on 4.4 though.
>
Just taking a quick look, but would something like this work?
I created this against v4.4.257.
-- Steve
diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h
index 04151ede8043..698404f092d0 100644
--- a/scripts/recordmcount.h
+++ b/scripts/recordmcount.h
@@ -437,6 +437,8 @@ static unsigned find_secsym_ndx(unsigned const txtndx,
if (w2(ehdr->e_machine) == EM_ARM
&& ELF_ST_TYPE(symp->st_info) == STT_FUNC)
continue;
+ if (ELF_ST_TYPE(symp->st_info) == STT_SECTION)
+ continue;
*recvalp = _w(symp->st_value);
return symp - sym0;
On Thu, Feb 11, 2021 at 09:32:03PM +0800, Xi Ruoyao wrote:
> Hi all,
>
> The latest GNU assembler (binutils-2.36.1) is removing unused section symbols
> like Clang [1]. So linux-5.10.15 can't be built with binutils-2.36.1 now. It
> has been reported as https://bugzilla.kernel.org/show_bug.cgi?id=211693.
>
> I can confirm this commit fixes the issue. It should be cherry-picked into
> stable branches, so the following stable releases will be able to built with
> latest GNU toolchain.
>
> [1]: https://sourceware.org/pipermail/binutils/2020-December/114671.html
>
> At last, happy new lunar year guys :).
>
> On 2020-12-16 13:49 +0000, tip-bot2 for Josh Poimboeuf wrote:
> > The following commit has been merged into the objtool/urgent branch of tip:
> >
> > Commit-ID:???? 44f6a7c0755d8dd453c70557e11687bb080a6f21
Now queued up for 5.10.y.
If people want it in older kernels, please provide a working backport.
thanks,
greg k-h
On Fri, Feb 12, 2021 at 12:45:47PM -0500, Steven Rostedt wrote:
> On Fri, 12 Feb 2021 11:07:50 -0600
> Josh Poimboeuf <[email protected]> wrote:
>
>
> > > Any ideas are appreciated.
> >
> > [ Adding Steve Rostedt ]
> >
> > This error message comes from recordmcount. It probably can't handle
> > the missing STT_SECTION symbols which are getting stripped by the new
> > binutils. (Objtool also had trouble with that.)
> >
> > No idea why you only see this on 4.4 though.
> >
>
> Just taking a quick look, but would something like this work?
>
> I created this against v4.4.257.
>
> -- Steve
>
> diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h
> index 04151ede8043..698404f092d0 100644
> --- a/scripts/recordmcount.h
> +++ b/scripts/recordmcount.h
> @@ -437,6 +437,8 @@ static unsigned find_secsym_ndx(unsigned const txtndx,
> if (w2(ehdr->e_machine) == EM_ARM
> && ELF_ST_TYPE(symp->st_info) == STT_FUNC)
> continue;
> + if (ELF_ST_TYPE(symp->st_info) == STT_SECTION)
> + continue;
>
> *recvalp = _w(symp->st_value);
> return symp - sym0;
>
Thanks for the patch, but no, still fails with:
Cannot find symbol for section 8: .text.unlikely.
kernel/kexec_file.o: failed
make[1]: *** [scripts/Makefile.build:277: kernel/kexec_file.o] Error 1
make[1]: *** Deleting file 'kernel/kexec_file.o'
On Sat, 13 Feb 2021 15:09:02 +0100
Greg Kroah-Hartman <[email protected]> wrote:
> Thanks for the patch, but no, still fails with:
>
> Cannot find symbol for section 8: .text.unlikely.
> kernel/kexec_file.o: failed
> make[1]: *** [scripts/Makefile.build:277: kernel/kexec_file.o] Error 1
> make[1]: *** Deleting file 'kernel/kexec_file.o'
It was just a guess.
I guess I'll need to find some time next week to set up a VM with
binutils 2.36 (I just checked, and all my development machines have
2.35). Then I'll be able to try and debug it.
-- Steve
On Sat, Feb 13, 2021 at 09:13:04AM -0500, Steven Rostedt wrote:
> On Sat, 13 Feb 2021 15:09:02 +0100
> Greg Kroah-Hartman <[email protected]> wrote:
>
> > Thanks for the patch, but no, still fails with:
> >
> > Cannot find symbol for section 8: .text.unlikely.
> > kernel/kexec_file.o: failed
> > make[1]: *** [scripts/Makefile.build:277: kernel/kexec_file.o] Error 1
> > make[1]: *** Deleting file 'kernel/kexec_file.o'
>
> It was just a guess.
>
> I guess I'll need to find some time next week to set up a VM with
> binutils 2.36 (I just checked, and all my development machines have
> 2.35). Then I'll be able to try and debug it.
FWIW, I wasn't able to recreate. I tried both binutils 2.36 and
2.36.1, with gcc 11 and a 'make allmodconfig' kernel.
--
Josh
On Sat, Feb 13, 2021 at 09:52:03AM -0600, Josh Poimboeuf wrote:
> On Sat, Feb 13, 2021 at 09:13:04AM -0500, Steven Rostedt wrote:
> > On Sat, 13 Feb 2021 15:09:02 +0100
> > Greg Kroah-Hartman <[email protected]> wrote:
> >
> > > Thanks for the patch, but no, still fails with:
> > >
> > > Cannot find symbol for section 8: .text.unlikely.
> > > kernel/kexec_file.o: failed
> > > make[1]: *** [scripts/Makefile.build:277: kernel/kexec_file.o] Error 1
> > > make[1]: *** Deleting file 'kernel/kexec_file.o'
> >
> > It was just a guess.
> >
> > I guess I'll need to find some time next week to set up a VM with
> > binutils 2.36 (I just checked, and all my development machines have
> > 2.35). Then I'll be able to try and debug it.
>
> FWIW, I wasn't able to recreate. I tried both binutils 2.36 and
> 2.36.1, with gcc 11 and a 'make allmodconfig' kernel.
I'm using whatever the latest is in Arch, which is gcc 10.2 and binutils
2.36. My config is here:
https://github.com/gregkh/gregkh-linux/blob/master/stable/configs/4.4.y
thanks,
greg k-h
On Sat, Feb 13, 2021 at 05:25:18PM +0100, Greg Kroah-Hartman wrote:
> On Sat, Feb 13, 2021 at 09:52:03AM -0600, Josh Poimboeuf wrote:
> > On Sat, Feb 13, 2021 at 09:13:04AM -0500, Steven Rostedt wrote:
> > > On Sat, 13 Feb 2021 15:09:02 +0100
> > > Greg Kroah-Hartman <[email protected]> wrote:
> > >
> > > > Thanks for the patch, but no, still fails with:
> > > >
> > > > Cannot find symbol for section 8: .text.unlikely.
> > > > kernel/kexec_file.o: failed
> > > > make[1]: *** [scripts/Makefile.build:277: kernel/kexec_file.o] Error 1
> > > > make[1]: *** Deleting file 'kernel/kexec_file.o'
> > >
> > > It was just a guess.
> > >
> > > I guess I'll need to find some time next week to set up a VM with
> > > binutils 2.36 (I just checked, and all my development machines have
> > > 2.35). Then I'll be able to try and debug it.
> >
> > FWIW, I wasn't able to recreate. I tried both binutils 2.36 and
> > 2.36.1, with gcc 11 and a 'make allmodconfig' kernel.
>
> I'm using whatever the latest is in Arch, which is gcc 10.2 and binutils
> 2.36. My config is here:
> https://github.com/gregkh/gregkh-linux/blob/master/stable/configs/4.4.y
Ok, I was able to recreate with that config.
GCC places two weak functions (arch_kexec_apply_relocations_add() and
arch_kexec_apply_relocations()) in .text.unlikely (probably because
printk() is __cold), and then the assembler doesn't generate the
'.text.unlikely' symbol because no other code references it.
Steve, looks like recordmcount avoids referencing weak symbols directly
by their function symbol. Maybe it can just skip weak symbols which
don't have a section symbol, since this seems like a rare scenario.
Here's a total hack fix. Just remove the functions, awkwardly avoiding
the problem.
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 6030efd4a188..456e3427c5e5 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -115,24 +115,6 @@ int __weak arch_kexec_kernel_verify_sig(struct kimage *image, void *buf,
return -EKEYREJECTED;
}
-/* Apply relocations of type RELA */
-int __weak
-arch_kexec_apply_relocations_add(const Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
- unsigned int relsec)
-{
- pr_err("RELA relocation unsupported.\n");
- return -ENOEXEC;
-}
-
-/* Apply relocations of type REL */
-int __weak
-arch_kexec_apply_relocations(const Elf_Ehdr *ehdr, Elf_Shdr *sechdrs,
- unsigned int relsec)
-{
- pr_err("REL relocation unsupported.\n");
- return -ENOEXEC;
-}
-
/*
* Free up memory used by kernel, initrd, and command line. This is temporary
* memory allocation which is not needed any more after these buffers have
On Sun, 14 Feb 2021 09:51:47 -0600
Josh Poimboeuf <[email protected]> wrote:
> Steve, looks like recordmcount avoids referencing weak symbols directly
> by their function symbol. Maybe it can just skip weak symbols which
> don't have a section symbol, since this seems like a rare scenario.
When does the .text.unlikely section disappear? During the creation of the
object, or later in the linker stage?
-- Steve
On Mon, Feb 15, 2021 at 09:53:07AM -0500, Steven Rostedt wrote:
> On Sun, 14 Feb 2021 09:51:47 -0600
> Josh Poimboeuf <[email protected]> wrote:
>
> > Steve, looks like recordmcount avoids referencing weak symbols directly
> > by their function symbol. Maybe it can just skip weak symbols which
> > don't have a section symbol, since this seems like a rare scenario.
>
> When does the .text.unlikely section disappear? During the creation of the
> object, or later in the linker stage?
The section is there, but the symbol associated with the section
(".text.unlikely" symbol) isn't generated by the assembler.
--
Josh
On Mon, 15 Feb 2021 09:58:06 -0600
Josh Poimboeuf <[email protected]> wrote:
> On Mon, Feb 15, 2021 at 09:53:07AM -0500, Steven Rostedt wrote:
> > On Sun, 14 Feb 2021 09:51:47 -0600
> > Josh Poimboeuf <[email protected]> wrote:
> >
> > > Steve, looks like recordmcount avoids referencing weak symbols directly
> > > by their function symbol. Maybe it can just skip weak symbols which
> > > don't have a section symbol, since this seems like a rare scenario.
> >
> > When does the .text.unlikely section disappear? During the creation of the
> > object, or later in the linker stage?
>
> The section is there, but the symbol associated with the section
> (".text.unlikely" symbol) isn't generated by the assembler.
>
Greg,
Does this fix the issue with you? It appears to fix it for my arch linux
VM that I created that uses binutils 2.36-3.
-- Steve
diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h
index f9b19524da11..558b67f8364e 100644
--- a/scripts/recordmcount.h
+++ b/scripts/recordmcount.h
@@ -562,7 +562,7 @@ static char const * __has_rel_mcount(Elf_Shdr const *const relhdr, /* reltype */
if (w(txthdr->sh_type) != SHT_PROGBITS ||
!(_w(txthdr->sh_flags) & SHF_EXECINSTR))
return NULL;
- return txtname;
+ return shdr0->sh_size ? txtname : NULL;
}
static char const *has_rel_mcount(Elf_Shdr const *const relhdr,