* Compile error ppc64le: Cannot find symbol for section 11: .text.unlikely. @ 2021-11-24 12:47 Veronika Kabatova 2021-11-24 13:47 ` Baoquan He 0 siblings, 1 reply; 9+ messages in thread From: Veronika Kabatova @ 2021-11-24 12:47 UTC (permalink / raw) To: kexec; +Cc: ebiederm Hi, for a while we've been seen the following error when compiling the mainline kernel with gcc 11.2 and binutils 2.37: 00:02:32 Cannot find symbol for section 11: .text.unlikely. 00:02:32 kernel/kexec_file.o: failed 00:02:32 make[3]: *** [scripts/Makefile.build:287: kernel/kexec_file.o] Error 1 00:02:32 make[3]: *** Deleting file 'kernel/kexec_file.o' 00:02:32 make[2]: *** [Makefile:1846: kernel] Error 2 00:02:32 make[2]: *** Waiting for unfinished jobs.... The error only happens with ppc64le. I've tested this with cross compilation, but the only reference to the error I found suggests the same happens with the native compiles as well: https://github.com/groeck/linux-build-test/commit/142cbefbc0d37962c9a6c7f28ee415ecd5fd1e98 In case it matters, the config used is the Fedora config with kselftest options enabled, which you can grab from https://gitlab.com/redhat/red-hat-ci-tools/kernel/cki-internal-pipelines/cki-trusted-contributors/-/jobs/1760752896/artifacts/raw/artifacts/kernel-mainline.kernel.org-ppc64le-e4e737bb5c170df6135a127739a9e6148ee3da82.config I've reached out to the Fedora compiler folks and Nick Clifton suggested this is a problem with the kernel: This message comes from the recordmcount tool, which is part of the kernel sources: linux/scripts/recordmcount.[ch] It appears to be triggered when a compiler update causes code to be rearranged. The problem has been reported before in various forums, but in particular I found this reference: https://lore.kernel.org/lkml/20201204165742.3815221-2-arnd@kernel.org/ The point of which to me at least is that this is a kernel issue rather than a compiler issue. Ie there must be some weak symbols in kexec_file.o file which need to be moved elsewhere. Is this something that is indeed an issue that should be fixed in the kernel, or should I reach out to someone else? I'm happy to test any patches provided. Thank you, Veronika _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Compile error ppc64le: Cannot find symbol for section 11: .text.unlikely. 2021-11-24 12:47 Compile error ppc64le: Cannot find symbol for section 11: .text.unlikely Veronika Kabatova @ 2021-11-24 13:47 ` Baoquan He 2021-12-01 2:19 ` Coiby Xu 0 siblings, 1 reply; 9+ messages in thread From: Baoquan He @ 2021-11-24 13:47 UTC (permalink / raw) To: Veronika Kabatova; +Cc: kexec, ebiederm, coxu On 11/24/21 at 01:47pm, Veronika Kabatova wrote: > Hi, > > for a while we've been seen the following error when compiling > the mainline kernel with gcc 11.2 and binutils 2.37: > > 00:02:32 Cannot find symbol for section 11: .text.unlikely. > 00:02:32 kernel/kexec_file.o: failed > 00:02:32 make[3]: *** [scripts/Makefile.build:287: kernel/kexec_file.o] Error 1 > 00:02:32 make[3]: *** Deleting file 'kernel/kexec_file.o' > 00:02:32 make[2]: *** [Makefile:1846: kernel] Error 2 > 00:02:32 make[2]: *** Waiting for unfinished jobs.... > > The error only happens with ppc64le. I've tested this with cross > compilation, but the only reference to the error I found suggests > the same happens with the native compiles as well: > > https://github.com/groeck/linux-build-test/commit/142cbefbc0d37962c9a6c7f28ee415ecd5fd1e98 > > In case it matters, the config used is the Fedora config with > kselftest options enabled, which you can grab from > > https://gitlab.com/redhat/red-hat-ci-tools/kernel/cki-internal-pipelines/cki-trusted-contributors/-/jobs/1760752896/artifacts/raw/artifacts/kernel-mainline.kernel.org-ppc64le-e4e737bb5c170df6135a127739a9e6148ee3da82.config > > > I've reached out to the Fedora compiler folks and Nick Clifton > suggested this is a problem with the kernel: > > This message comes from the recordmcount tool, which is part of the kernel > sources: > > linux/scripts/recordmcount.[ch] > > It appears to be triggered when a compiler update causes code to be > rearranged. The problem has been reported before in various forums, > but in particular I found this reference: > > https://lore.kernel.org/lkml/20201204165742.3815221-2-arnd@kernel.org/ > > The point of which to me at least is that this is a kernel issue rather than > a compiler issue. Ie there must be some weak symbols in kexec_file.o file > which need to be moved elsewhere. It could be arch_kexec_kernel_verify_sig() in kernel/kexec_file.c which is __weak, but not implemented in any ARCH. If true, this has been pointed out by Eric in one patch thread from Coiby. [PATCH v3 1/3] kexec: clean up arch_kexec_kernel_verify_sig http://lkml.kernel.org/r/20211018083137.338757-2-coxu@redhat.com Maybe Coiby can fetch above config file and run the test to check. Thanks Baoquan _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Compile error ppc64le: Cannot find symbol for section 11: .text.unlikely. 2021-11-24 13:47 ` Baoquan He @ 2021-12-01 2:19 ` Coiby Xu 2021-12-01 2:26 ` Coiby Xu 2021-12-03 15:54 ` Veronika Kabatova 0 siblings, 2 replies; 9+ messages in thread From: Coiby Xu @ 2021-12-01 2:19 UTC (permalink / raw) To: Baoquan He; +Cc: Veronika Kabatova, kexec, ebiederm [-- Attachment #1: Type: text/plain, Size: 2821 bytes --] On Wed, Nov 24, 2021 at 09:47:43PM +0800, Baoquan He wrote: >On 11/24/21 at 01:47pm, Veronika Kabatova wrote: >> Hi, >> >> for a while we've been seen the following error when compiling >> the mainline kernel with gcc 11.2 and binutils 2.37: >> >> 00:02:32 Cannot find symbol for section 11: .text.unlikely. >> 00:02:32 kernel/kexec_file.o: failed >> 00:02:32 make[3]: *** [scripts/Makefile.build:287: kernel/kexec_file.o] Error 1 >> 00:02:32 make[3]: *** Deleting file 'kernel/kexec_file.o' >> 00:02:32 make[2]: *** [Makefile:1846: kernel] Error 2 >> 00:02:32 make[2]: *** Waiting for unfinished jobs.... >> >> The error only happens with ppc64le. I've tested this with cross >> compilation, but the only reference to the error I found suggests >> the same happens with the native compiles as well: >> >> https://github.com/groeck/linux-build-test/commit/142cbefbc0d37962c9a6c7f28ee415ecd5fd1e98 >> >> In case it matters, the config used is the Fedora config with >> kselftest options enabled, which you can grab from >> >> https://gitlab.com/redhat/red-hat-ci-tools/kernel/cki-internal-pipelines/cki-trusted-contributors/-/jobs/1760752896/artifacts/raw/artifacts/kernel-mainline.kernel.org-ppc64le-e4e737bb5c170df6135a127739a9e6148ee3da82.config >> >> >> I've reached out to the Fedora compiler folks and Nick Clifton >> suggested this is a problem with the kernel: >> >> This message comes from the recordmcount tool, which is part of the kernel >> sources: >> >> linux/scripts/recordmcount.[ch] >> >> It appears to be triggered when a compiler update causes code to be >> rearranged. The problem has been reported before in various forums, >> but in particular I found this reference: >> >> https://lore.kernel.org/lkml/20201204165742.3815221-2-arnd@kernel.org/ >> >> The point of which to me at least is that this is a kernel issue rather than >> a compiler issue. Ie there must be some weak symbols in kexec_file.o file >> which need to be moved elsewhere. > >It could be arch_kexec_kernel_verify_sig() in kernel/kexec_file.c which >is __weak, but not implemented in any ARCH. If true, this has been >pointed out by Eric in one patch thread from Coiby. > >[PATCH v3 1/3] kexec: clean up arch_kexec_kernel_verify_sig >http://lkml.kernel.org/r/20211018083137.338757-2-coxu@redhat.com > >Maybe Coiby can fetch above config file and run the test to check. "[PATCH v3 1/3] kexec: clean up arch_kexec_kernel_verify_sig" alone would fix the error. If I turn arch_kexec_apply_relocations{_add,} into static function, the error would be gone. As attached is the patch would make this error disappear. However, s390 and x86 have its own implementation of arch_kexec_apply_relocations_add. This makes it looks like to be gcc's issue. > >Thanks >Baoquan > -- Best regards, Coiby [-- Attachment #2: 0001-fix-error-ppc64le-Cannot-find-symbol-for-section-11-.patch --] [-- Type: text/plain, Size: 4069 bytes --] From 49e0333f5a0743cdcc99777218524d6a6cd5ec34 Mon Sep 17 00:00:00 2001 From: Coiby Xu <coxu@redhat.com> Date: Mon, 18 Oct 2021 15:52:46 +0800 Subject: [PATCH] fix error "ppc64le: Cannot find symbol for section 11: .text.unlikely." --- include/linux/kexec.h | 13 ------------- kernel/kexec_file.c | 40 ++++++++++++++++------------------------ 2 files changed, 16 insertions(+), 37 deletions(-) diff --git a/include/linux/kexec.h b/include/linux/kexec.h index 0c994ae37..1476470a1 100644 --- a/include/linux/kexec.h +++ b/include/linux/kexec.h @@ -186,20 +186,7 @@ void *kexec_purgatory_get_symbol_addr(struct kimage *image, const char *name); /* Architectures may override the below functions */ int arch_kexec_kernel_image_probe(struct kimage *image, void *buf, unsigned long buf_len); -void *arch_kexec_kernel_image_load(struct kimage *image); -int arch_kexec_apply_relocations_add(struct purgatory_info *pi, - Elf_Shdr *section, - const Elf_Shdr *relsec, - const Elf_Shdr *symtab); -int arch_kexec_apply_relocations(struct purgatory_info *pi, - Elf_Shdr *section, - const Elf_Shdr *relsec, - const Elf_Shdr *symtab); int arch_kimage_file_post_load_cleanup(struct kimage *image); -#ifdef CONFIG_KEXEC_SIG -int arch_kexec_kernel_verify_sig(struct kimage *image, void *buf, - unsigned long buf_len); -#endif int arch_kexec_locate_mem_hole(struct kexec_buf *kbuf); extern int kexec_add_buffer(struct kexec_buf *kbuf); diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c index 8347fc158..e0afe36d3 100644 --- a/kernel/kexec_file.c +++ b/kernel/kexec_file.c @@ -71,7 +71,7 @@ static void *kexec_image_load_default(struct kimage *image) image->cmdline_buf_len); } -void * __weak arch_kexec_kernel_image_load(struct kimage *image) +static void * arch_kexec_kernel_image_load(struct kimage *image) { return kexec_image_load_default(image); } @@ -89,25 +89,6 @@ int __weak arch_kimage_file_post_load_cleanup(struct kimage *image) return kexec_image_post_load_cleanup_default(image); } -#ifdef CONFIG_KEXEC_SIG -static int kexec_image_verify_sig_default(struct kimage *image, void *buf, - unsigned long buf_len) -{ - if (!image->fops || !image->fops->verify_sig) { - pr_debug("kernel loader does not support signature verification.\n"); - return -EKEYREJECTED; - } - - return image->fops->verify_sig(buf, buf_len); -} - -int __weak arch_kexec_kernel_verify_sig(struct kimage *image, void *buf, - unsigned long buf_len) -{ - return kexec_image_verify_sig_default(image, buf, buf_len); -} -#endif - /* * arch_kexec_apply_relocations_add - apply relocations of type RELA * @pi: Purgatory to be relocated. @@ -117,7 +98,7 @@ int __weak arch_kexec_kernel_verify_sig(struct kimage *image, void *buf, * * Return: 0 on success, negative errno on error. */ -int __weak +static int arch_kexec_apply_relocations_add(struct purgatory_info *pi, Elf_Shdr *section, const Elf_Shdr *relsec, const Elf_Shdr *symtab) { @@ -134,7 +115,7 @@ arch_kexec_apply_relocations_add(struct purgatory_info *pi, Elf_Shdr *section, * * Return: 0 on success, negative errno on error. */ -int __weak +static int arch_kexec_apply_relocations(struct purgatory_info *pi, Elf_Shdr *section, const Elf_Shdr *relsec, const Elf_Shdr *symtab) { @@ -184,13 +165,24 @@ void kimage_file_post_load_cleanup(struct kimage *image) } #ifdef CONFIG_KEXEC_SIG +static int kexec_image_verify_sig(struct kimage *image, void *buf, + unsigned long buf_len) +{ + if (!image->fops || !image->fops->verify_sig) { + pr_debug("kernel loader does not support signature verification.\n"); + return -EKEYREJECTED; + } + + return image->fops->verify_sig(buf, buf_len); +} + static int kimage_validate_signature(struct kimage *image) { int ret; - ret = arch_kexec_kernel_verify_sig(image, image->kernel_buf, - image->kernel_buf_len); + ret = kexec_image_verify_sig(image, image->kernel_buf, + image->kernel_buf_len); if (ret) { if (IS_ENABLED(CONFIG_KEXEC_SIG_FORCE)) { -- 2.33.1 [-- Attachment #3: Type: text/plain, Size: 143 bytes --] _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: Compile error ppc64le: Cannot find symbol for section 11: .text.unlikely. 2021-12-01 2:19 ` Coiby Xu @ 2021-12-01 2:26 ` Coiby Xu 2021-12-03 15:54 ` Veronika Kabatova 1 sibling, 0 replies; 9+ messages in thread From: Coiby Xu @ 2021-12-01 2:26 UTC (permalink / raw) To: Baoquan He; +Cc: Veronika Kabatova, kexec, ebiederm On Wed, Dec 01, 2021 at 10:19:26AM +0800, Coiby Xu wrote: >On Wed, Nov 24, 2021 at 09:47:43PM +0800, Baoquan He wrote: >>On 11/24/21 at 01:47pm, Veronika Kabatova wrote: >>>Hi, >>> >>>for a while we've been seen the following error when compiling >>>the mainline kernel with gcc 11.2 and binutils 2.37: >>> >>>00:02:32 Cannot find symbol for section 11: .text.unlikely. >>>00:02:32 kernel/kexec_file.o: failed >>>00:02:32 make[3]: *** [scripts/Makefile.build:287: kernel/kexec_file.o] Error 1 >>>00:02:32 make[3]: *** Deleting file 'kernel/kexec_file.o' >>>00:02:32 make[2]: *** [Makefile:1846: kernel] Error 2 >>>00:02:32 make[2]: *** Waiting for unfinished jobs.... >>> >>>The error only happens with ppc64le. I've tested this with cross >>>compilation, but the only reference to the error I found suggests >>>the same happens with the native compiles as well: >>> >>>https://github.com/groeck/linux-build-test/commit/142cbefbc0d37962c9a6c7f28ee415ecd5fd1e98 >>> >>>In case it matters, the config used is the Fedora config with >>>kselftest options enabled, which you can grab from >>> >>>https://gitlab.com/redhat/red-hat-ci-tools/kernel/cki-internal-pipelines/cki-trusted-contributors/-/jobs/1760752896/artifacts/raw/artifacts/kernel-mainline.kernel.org-ppc64le-e4e737bb5c170df6135a127739a9e6148ee3da82.config >>> >>> >>>I've reached out to the Fedora compiler folks and Nick Clifton >>>suggested this is a problem with the kernel: >>> >>> This message comes from the recordmcount tool, which is part of the kernel >>> sources: >>> >>> linux/scripts/recordmcount.[ch] >>> >>> It appears to be triggered when a compiler update causes code to be >>> rearranged. The problem has been reported before in various forums, >>> but in particular I found this reference: >>> >>> https://lore.kernel.org/lkml/20201204165742.3815221-2-arnd@kernel.org/ >>> >>> The point of which to me at least is that this is a kernel issue rather than >>> a compiler issue. Ie there must be some weak symbols in kexec_file.o file >>> which need to be moved elsewhere. >> >>It could be arch_kexec_kernel_verify_sig() in kernel/kexec_file.c which >>is __weak, but not implemented in any ARCH. If true, this has been >>pointed out by Eric in one patch thread from Coiby. >> >>[PATCH v3 1/3] kexec: clean up arch_kexec_kernel_verify_sig >>http://lkml.kernel.org/r/20211018083137.338757-2-coxu@redhat.com >> >>Maybe Coiby can fetch above config file and run the test to check. > >"[PATCH v3 1/3] kexec: clean up arch_kexec_kernel_verify_sig" alone >would fix the error. If I turn arch_kexec_apply_relocations{_add,} into ^^^^^ wouldn't Sorry I made a typo. >static function, the error would be gone. As attached is the patch would >make this error disappear. > >However, s390 and x86 have its own implementation of >arch_kexec_apply_relocations_add. This makes it looks like to be gcc's >issue. > > >> >>Thanks >>Baoquan >> > >-- >Best regards, >Coiby From 49e0333f5a0743cdcc99777218524d6a6cd5ec34 Mon Sep 17 00:00:00 2001 >From: Coiby Xu <coxu@redhat.com> >Date: Mon, 18 Oct 2021 15:52:46 +0800 >Subject: [PATCH] fix error "ppc64le: Cannot find symbol for section 11: > .text.unlikely." > >--- > include/linux/kexec.h | 13 ------------- > kernel/kexec_file.c | 40 ++++++++++++++++------------------------ > 2 files changed, 16 insertions(+), 37 deletions(-) > >diff --git a/include/linux/kexec.h b/include/linux/kexec.h >index 0c994ae37..1476470a1 100644 >--- a/include/linux/kexec.h >+++ b/include/linux/kexec.h >@@ -186,20 +186,7 @@ void *kexec_purgatory_get_symbol_addr(struct kimage *image, const char *name); > /* Architectures may override the below functions */ > int arch_kexec_kernel_image_probe(struct kimage *image, void *buf, > unsigned long buf_len); >-void *arch_kexec_kernel_image_load(struct kimage *image); >-int arch_kexec_apply_relocations_add(struct purgatory_info *pi, >- Elf_Shdr *section, >- const Elf_Shdr *relsec, >- const Elf_Shdr *symtab); >-int arch_kexec_apply_relocations(struct purgatory_info *pi, >- Elf_Shdr *section, >- const Elf_Shdr *relsec, >- const Elf_Shdr *symtab); > int arch_kimage_file_post_load_cleanup(struct kimage *image); >-#ifdef CONFIG_KEXEC_SIG >-int arch_kexec_kernel_verify_sig(struct kimage *image, void *buf, >- unsigned long buf_len); >-#endif > int arch_kexec_locate_mem_hole(struct kexec_buf *kbuf); > > extern int kexec_add_buffer(struct kexec_buf *kbuf); >diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c >index 8347fc158..e0afe36d3 100644 >--- a/kernel/kexec_file.c >+++ b/kernel/kexec_file.c >@@ -71,7 +71,7 @@ static void *kexec_image_load_default(struct kimage *image) > image->cmdline_buf_len); > } > >-void * __weak arch_kexec_kernel_image_load(struct kimage *image) >+static void * arch_kexec_kernel_image_load(struct kimage *image) > { > return kexec_image_load_default(image); > } >@@ -89,25 +89,6 @@ int __weak arch_kimage_file_post_load_cleanup(struct kimage *image) > return kexec_image_post_load_cleanup_default(image); > } > >-#ifdef CONFIG_KEXEC_SIG >-static int kexec_image_verify_sig_default(struct kimage *image, void *buf, >- unsigned long buf_len) >-{ >- if (!image->fops || !image->fops->verify_sig) { >- pr_debug("kernel loader does not support signature verification.\n"); >- return -EKEYREJECTED; >- } >- >- return image->fops->verify_sig(buf, buf_len); >-} >- >-int __weak arch_kexec_kernel_verify_sig(struct kimage *image, void *buf, >- unsigned long buf_len) >-{ >- return kexec_image_verify_sig_default(image, buf, buf_len); >-} >-#endif >- > /* > * arch_kexec_apply_relocations_add - apply relocations of type RELA > * @pi: Purgatory to be relocated. >@@ -117,7 +98,7 @@ int __weak arch_kexec_kernel_verify_sig(struct kimage *image, void *buf, > * > * Return: 0 on success, negative errno on error. > */ >-int __weak >+static int > arch_kexec_apply_relocations_add(struct purgatory_info *pi, Elf_Shdr *section, > const Elf_Shdr *relsec, const Elf_Shdr *symtab) > { >@@ -134,7 +115,7 @@ arch_kexec_apply_relocations_add(struct purgatory_info *pi, Elf_Shdr *section, > * > * Return: 0 on success, negative errno on error. > */ >-int __weak >+static int > arch_kexec_apply_relocations(struct purgatory_info *pi, Elf_Shdr *section, > const Elf_Shdr *relsec, const Elf_Shdr *symtab) > { >@@ -184,13 +165,24 @@ void kimage_file_post_load_cleanup(struct kimage *image) > } > > #ifdef CONFIG_KEXEC_SIG >+static int kexec_image_verify_sig(struct kimage *image, void *buf, >+ unsigned long buf_len) >+{ >+ if (!image->fops || !image->fops->verify_sig) { >+ pr_debug("kernel loader does not support signature verification.\n"); >+ return -EKEYREJECTED; >+ } >+ >+ return image->fops->verify_sig(buf, buf_len); >+} >+ > static int > kimage_validate_signature(struct kimage *image) > { > int ret; > >- ret = arch_kexec_kernel_verify_sig(image, image->kernel_buf, >- image->kernel_buf_len); >+ ret = kexec_image_verify_sig(image, image->kernel_buf, >+ image->kernel_buf_len); > if (ret) { > > if (IS_ENABLED(CONFIG_KEXEC_SIG_FORCE)) { >-- >2.33.1 > -- Best regards, Coiby _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Compile error ppc64le: Cannot find symbol for section 11: .text.unlikely. 2021-12-01 2:19 ` Coiby Xu 2021-12-01 2:26 ` Coiby Xu @ 2021-12-03 15:54 ` Veronika Kabatova 2022-02-25 3:46 ` Coiby Xu 1 sibling, 1 reply; 9+ messages in thread From: Veronika Kabatova @ 2021-12-03 15:54 UTC (permalink / raw) To: Coiby Xu; +Cc: Baoquan He, kexec, ebiederm On Wed, Dec 1, 2021 at 3:20 AM Coiby Xu <coxu@redhat.com> wrote: > > On Wed, Nov 24, 2021 at 09:47:43PM +0800, Baoquan He wrote: > >On 11/24/21 at 01:47pm, Veronika Kabatova wrote: > >> Hi, > >> > >> for a while we've been seen the following error when compiling > >> the mainline kernel with gcc 11.2 and binutils 2.37: > >> > >> 00:02:32 Cannot find symbol for section 11: .text.unlikely. > >> 00:02:32 kernel/kexec_file.o: failed > >> 00:02:32 make[3]: *** [scripts/Makefile.build:287: kernel/kexec_file.o] Error 1 > >> 00:02:32 make[3]: *** Deleting file 'kernel/kexec_file.o' > >> 00:02:32 make[2]: *** [Makefile:1846: kernel] Error 2 > >> 00:02:32 make[2]: *** Waiting for unfinished jobs.... > >> > >> The error only happens with ppc64le. I've tested this with cross > >> compilation, but the only reference to the error I found suggests > >> the same happens with the native compiles as well: > >> > >> https://github.com/groeck/linux-build-test/commit/142cbefbc0d37962c9a6c7f28ee415ecd5fd1e98 > >> > >> In case it matters, the config used is the Fedora config with > >> kselftest options enabled, which you can grab from > >> > >> https://gitlab.com/redhat/red-hat-ci-tools/kernel/cki-internal-pipelines/cki-trusted-contributors/-/jobs/1760752896/artifacts/raw/artifacts/kernel-mainline.kernel.org-ppc64le-e4e737bb5c170df6135a127739a9e6148ee3da82.config > >> > >> > >> I've reached out to the Fedora compiler folks and Nick Clifton > >> suggested this is a problem with the kernel: > >> > >> This message comes from the recordmcount tool, which is part of the kernel > >> sources: > >> > >> linux/scripts/recordmcount.[ch] > >> > >> It appears to be triggered when a compiler update causes code to be > >> rearranged. The problem has been reported before in various forums, > >> but in particular I found this reference: > >> > >> https://lore.kernel.org/lkml/20201204165742.3815221-2-arnd@kernel.org/ > >> > >> The point of which to me at least is that this is a kernel issue rather than > >> a compiler issue. Ie there must be some weak symbols in kexec_file.o file > >> which need to be moved elsewhere. > > > >It could be arch_kexec_kernel_verify_sig() in kernel/kexec_file.c which > >is __weak, but not implemented in any ARCH. If true, this has been > >pointed out by Eric in one patch thread from Coiby. > > > >[PATCH v3 1/3] kexec: clean up arch_kexec_kernel_verify_sig > >http://lkml.kernel.org/r/20211018083137.338757-2-coxu@redhat.com > > > >Maybe Coiby can fetch above config file and run the test to check. > > "[PATCH v3 1/3] kexec: clean up arch_kexec_kernel_verify_sig" alone > would fix the error. If I turn arch_kexec_apply_relocations{_add,} into > static function, the error would be gone. As attached is the patch would > make this error disappear. > Thank you! I can confirm the attached patch fixes the problem. Veronika > However, s390 and x86 have its own implementation of > arch_kexec_apply_relocations_add. This makes it looks like to be gcc's > issue. > > > > > >Thanks > >Baoquan > > > > -- > Best regards, > Coiby _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 9+ messages in thread
* Compile error ppc64le: Cannot find symbol for section 11: .text.unlikely. 2021-12-03 15:54 ` Veronika Kabatova @ 2022-02-25 3:46 ` Coiby Xu 2022-03-02 7:46 ` Coiby Xu 0 siblings, 1 reply; 9+ messages in thread From: Coiby Xu @ 2022-02-25 3:46 UTC (permalink / raw) To: kexec On Fri, Dec 03, 2021 at 04:54:19PM +0100, Veronika Kabatova wrote: >On Wed, Dec 1, 2021 at 3:20 AM Coiby Xu <coxu@redhat.com> wrote: >> >> On Wed, Nov 24, 2021 at 09:47:43PM +0800, Baoquan He wrote: >> >On 11/24/21 at 01:47pm, Veronika Kabatova wrote: >> >> Hi, >> >> >> >> for a while we've been seen the following error when compiling >> >> the mainline kernel with gcc 11.2 and binutils 2.37: >> >> >> >> 00:02:32 Cannot find symbol for section 11: .text.unlikely. >> >> 00:02:32 kernel/kexec_file.o: failed >> >> 00:02:32 make[3]: *** [scripts/Makefile.build:287: kernel/kexec_file.o] Error 1 >> >> 00:02:32 make[3]: *** Deleting file 'kernel/kexec_file.o' >> >> 00:02:32 make[2]: *** [Makefile:1846: kernel] Error 2 >> >> 00:02:32 make[2]: *** Waiting for unfinished jobs.... >> >> >> >> The error only happens with ppc64le. I've tested this with cross >> >> compilation, but the only reference to the error I found suggests >> >> the same happens with the native compiles as well: >> >> >> >> https://github.com/groeck/linux-build-test/commit/142cbefbc0d37962c9a6c7f28ee415ecd5fd1e98 >> >> >> >> In case it matters, the config used is the Fedora config with >> >> kselftest options enabled, which you can grab from >> >> >> >> https://gitlab.com/redhat/red-hat-ci-tools/kernel/cki-internal-pipelines/cki-trusted-contributors/-/jobs/1760752896/artifacts/raw/artifacts/kernel-mainline.kernel.org-ppc64le-e4e737bb5c170df6135a127739a9e6148ee3da82.config >> >> >> >> >> >> I've reached out to the Fedora compiler folks and Nick Clifton >> >> suggested this is a problem with the kernel: >> >> >> >> This message comes from the recordmcount tool, which is part of the kernel >> >> sources: >> >> >> >> linux/scripts/recordmcount.[ch] >> >> >> >> It appears to be triggered when a compiler update causes code to be >> >> rearranged. The problem has been reported before in various forums, >> >> but in particular I found this reference: >> >> >> >> https://lore.kernel.org/lkml/20201204165742.3815221-2-arnd at kernel.org/ >> >> >> >> The point of which to me at least is that this is a kernel issue rather than >> >> a compiler issue. Ie there must be some weak symbols in kexec_file.o file >> >> which need to be moved elsewhere. >> > >> >It could be arch_kexec_kernel_verify_sig() in kernel/kexec_file.c which >> >is __weak, but not implemented in any ARCH. If true, this has been >> >pointed out by Eric in one patch thread from Coiby. >> > >> >[PATCH v3 1/3] kexec: clean up arch_kexec_kernel_verify_sig >> >http://lkml.kernel.org/r/20211018083137.338757-2-coxu at redhat.com >> > >> >Maybe Coiby can fetch above config file and run the test to check. >> >> "[PATCH v3 1/3] kexec: clean up arch_kexec_kernel_verify_sig" alone >> would fix the error. If I turn arch_kexec_apply_relocations{_add,} into Sorry I meant "alone won't fix the error". >> static function, the error would be gone. As attached is the patch would >> make this error disappear. >> > >Thank you! I can confirm the attached patch fixes the problem. > > >Veronika > >> However, s390 and x86 have its own implementation of >> arch_kexec_apply_relocations_add. This makes it looks like to be gcc's >> issue. Based on the above point and further investigation, I think the root cause is find_secsym_ndx in linux/scripts/recordmcount.h, /* * Find a symbol in the given section, to be used as the base for relocating * the table of offsets of calls to mcount. A local or global symbol suffices, * but avoid a Weak symbol because it may be overridden; the change in value * would invalidate the relocations of the offsets of the calls to mcount. * Often the found symbol will be the unnamed local symbol generated by * GNU 'as' for the start of each section. For example: * Num: Value Size Type Bind Vis Ndx Name * 2: 00000000 0 SECTION LOCAL DEFAULT 1 */ static int find_secsym_ndx(unsigned const txtndx, char const *const txtname, uint_t *const recvalp, unsigned int *sym_index, Elf_Shdr const *const symhdr, Elf32_Word const *symtab, Elf32_Word const *symtab_shndx, Elf_Ehdr const *const ehdr) { ... if (txtndx == get_symindex(symp, symtab, symtab_shndx) /* avoid STB_WEAK */ fprintf(stderr, "Cannot find symbol for section %u: %s.\n", txtndx, txtname); This function prints the above warning after failing to find arch_kexec_kernel_verify_sig or arch_kexec_apply_relocations{_add,} in section 11: .text.unlikely. because it ignores the weak symbol and ppc64le doesn't its arch implementations of these functions. I'll see if I can fix it in linux/scripts/recordmcount.h. >> >> >> > >> >Thanks >> >Baoquan >> > >> >> -- >> Best regards, >> Coiby > -- Best regards, Coiby ^ permalink raw reply [flat|nested] 9+ messages in thread
* Compile error ppc64le: Cannot find symbol for section 11: .text.unlikely. 2022-02-25 3:46 ` Coiby Xu @ 2022-03-02 7:46 ` Coiby Xu 2022-03-02 10:52 ` Veronika Kabatova 0 siblings, 1 reply; 9+ messages in thread From: Coiby Xu @ 2022-03-02 7:46 UTC (permalink / raw) To: kexec On Fri, Feb 25, 2022 at 11:46:41AM +0800, Coiby Xu wrote: >On Fri, Dec 03, 2021 at 04:54:19PM +0100, Veronika Kabatova wrote: >>On Wed, Dec 1, 2021 at 3:20 AM Coiby Xu <coxu@redhat.com> wrote: >>> >>>On Wed, Nov 24, 2021 at 09:47:43PM +0800, Baoquan He wrote: >>>>On 11/24/21 at 01:47pm, Veronika Kabatova wrote: >>>>> Hi, >>>>> >>>>> for a while we've been seen the following error when compiling >>>>> the mainline kernel with gcc 11.2 and binutils 2.37: >>>>> >>>>> 00:02:32 Cannot find symbol for section 11: .text.unlikely. >>>>> 00:02:32 kernel/kexec_file.o: failed >>>>> 00:02:32 make[3]: *** [scripts/Makefile.build:287: kernel/kexec_file.o] Error 1 >>>>> 00:02:32 make[3]: *** Deleting file 'kernel/kexec_file.o' >>>>> 00:02:32 make[2]: *** [Makefile:1846: kernel] Error 2 >>>>> 00:02:32 make[2]: *** Waiting for unfinished jobs.... >>>>> >>>>> The error only happens with ppc64le. I've tested this with cross >>>>> compilation, but the only reference to the error I found suggests >>>>> the same happens with the native compiles as well: >>>>> >>>>> https://github.com/groeck/linux-build-test/commit/142cbefbc0d37962c9a6c7f28ee415ecd5fd1e98 >>>>> >>>>> In case it matters, the config used is the Fedora config with >>>>> kselftest options enabled, which you can grab from >>>>> >>>>> https://gitlab.com/redhat/red-hat-ci-tools/kernel/cki-internal-pipelines/cki-trusted-contributors/-/jobs/1760752896/artifacts/raw/artifacts/kernel-mainline.kernel.org-ppc64le-e4e737bb5c170df6135a127739a9e6148ee3da82.config >>>>> >>>>> >>>>> I've reached out to the Fedora compiler folks and Nick Clifton >>>>> suggested this is a problem with the kernel: >>>>> >>>>> This message comes from the recordmcount tool, which is part of the kernel >>>>> sources: >>>>> >>>>> linux/scripts/recordmcount.[ch] >>>>> >>>>> It appears to be triggered when a compiler update causes code to be >>>>> rearranged. The problem has been reported before in various forums, >>>>> but in particular I found this reference: >>>>> >>>>> https://lore.kernel.org/lkml/20201204165742.3815221-2-arnd at kernel.org/ >>>>> >>>>> The point of which to me at least is that this is a kernel issue rather than >>>>> a compiler issue. Ie there must be some weak symbols in kexec_file.o file >>>>> which need to be moved elsewhere. >>>> >>>>It could be arch_kexec_kernel_verify_sig() in kernel/kexec_file.c which >>>>is __weak, but not implemented in any ARCH. If true, this has been >>>>pointed out by Eric in one patch thread from Coiby. >>>> >>>>[PATCH v3 1/3] kexec: clean up arch_kexec_kernel_verify_sig >>>>http://lkml.kernel.org/r/20211018083137.338757-2-coxu at redhat.com >>>> >>>>Maybe Coiby can fetch above config file and run the test to check. >>> >>>"[PATCH v3 1/3] kexec: clean up arch_kexec_kernel_verify_sig" alone >>>would fix the error. If I turn arch_kexec_apply_relocations{_add,} into > >Sorry I meant "alone won't fix the error". > >>>static function, the error would be gone. As attached is the patch would >>>make this error disappear. >>> >> >>Thank you! I can confirm the attached patch fixes the problem. >> >> >>Veronika >> >>>However, s390 and x86 have its own implementation of >>>arch_kexec_apply_relocations_add. This makes it looks like to be gcc's >>>issue. > >Based on the above point and further investigation, I think the root cause is >find_secsym_ndx in linux/scripts/recordmcount.h, > /* > * Find a symbol in the given section, to be used as the base for relocating > * the table of offsets of calls to mcount. A local or global symbol suffices, > * but avoid a Weak symbol because it may be overridden; the change in value > * would invalidate the relocations of the offsets of the calls to mcount. > * Often the found symbol will be the unnamed local symbol generated by > * GNU 'as' for the start of each section. For example: > * Num: Value Size Type Bind Vis Ndx Name > * 2: 00000000 0 SECTION LOCAL DEFAULT 1 > */ > static int find_secsym_ndx(unsigned const txtndx, > char const *const txtname, > uint_t *const recvalp, > unsigned int *sym_index, > Elf_Shdr const *const symhdr, > Elf32_Word const *symtab, > Elf32_Word const *symtab_shndx, > Elf_Ehdr const *const ehdr) > { > ... > if (txtndx == get_symindex(symp, symtab, symtab_shndx) > /* avoid STB_WEAK */ > > fprintf(stderr, "Cannot find symbol for section %u: %s.\n", > txtndx, txtname); > >This function prints the above warning after failing to find >arch_kexec_kernel_verify_sig or arch_kexec_apply_relocations{_add,} in >section 11: .text.unlikely. because it ignores the weak symbol and ppc64le >doesn't its arch implementations of these functions. I'll see if I can fix >it in linux/scripts/recordmcount.h. After digging deeper into linux/scripts/recordmcount.h, I think this issue can be either fixed in the compiler or recordmcount. So I fild two bugs - gcc: https://bugzilla.redhat.com/show_bug.cgi?id=2059838 - linux/scripts/recordmcount.h: https://bugzilla.redhat.com/show_bug.cgi?id=2059842 > >>> >>> >>>> >>>>Thanks >>>>Baoquan >>>> >>> >>>-- >>>Best regards, >>>Coiby >> > >-- >Best regards, >Coiby -- Best regards, Coiby ^ permalink raw reply [flat|nested] 9+ messages in thread
* Compile error ppc64le: Cannot find symbol for section 11: .text.unlikely. 2022-03-02 7:46 ` Coiby Xu @ 2022-03-02 10:52 ` Veronika Kabatova 2022-03-03 0:49 ` Coiby Xu 0 siblings, 1 reply; 9+ messages in thread From: Veronika Kabatova @ 2022-03-02 10:52 UTC (permalink / raw) To: kexec On Wed, Mar 2, 2022 at 8:50 AM Coiby Xu <coxu@redhat.com> wrote: > > On Fri, Feb 25, 2022 at 11:46:41AM +0800, Coiby Xu wrote: > >On Fri, Dec 03, 2021 at 04:54:19PM +0100, Veronika Kabatova wrote: > >>On Wed, Dec 1, 2021 at 3:20 AM Coiby Xu <coxu@redhat.com> wrote: > >>> > >>>On Wed, Nov 24, 2021 at 09:47:43PM +0800, Baoquan He wrote: > >>>>On 11/24/21 at 01:47pm, Veronika Kabatova wrote: > >>>>> Hi, > >>>>> > >>>>> for a while we've been seen the following error when compiling > >>>>> the mainline kernel with gcc 11.2 and binutils 2.37: > >>>>> > >>>>> 00:02:32 Cannot find symbol for section 11: .text.unlikely. > >>>>> 00:02:32 kernel/kexec_file.o: failed > >>>>> 00:02:32 make[3]: *** [scripts/Makefile.build:287: kernel/kexec_file.o] Error 1 > >>>>> 00:02:32 make[3]: *** Deleting file 'kernel/kexec_file.o' > >>>>> 00:02:32 make[2]: *** [Makefile:1846: kernel] Error 2 > >>>>> 00:02:32 make[2]: *** Waiting for unfinished jobs.... > >>>>> > >>>>> The error only happens with ppc64le. I've tested this with cross > >>>>> compilation, but the only reference to the error I found suggests > >>>>> the same happens with the native compiles as well: > >>>>> > >>>>> https://github.com/groeck/linux-build-test/commit/142cbefbc0d37962c9a6c7f28ee415ecd5fd1e98 > >>>>> > >>>>> In case it matters, the config used is the Fedora config with > >>>>> kselftest options enabled, which you can grab from > >>>>> > >>>>> https://gitlab.com/redhat/red-hat-ci-tools/kernel/cki-internal-pipelines/cki-trusted-contributors/-/jobs/1760752896/artifacts/raw/artifacts/kernel-mainline.kernel.org-ppc64le-e4e737bb5c170df6135a127739a9e6148ee3da82.config > >>>>> > >>>>> > >>>>> I've reached out to the Fedora compiler folks and Nick Clifton > >>>>> suggested this is a problem with the kernel: > >>>>> > >>>>> This message comes from the recordmcount tool, which is part of the kernel > >>>>> sources: > >>>>> > >>>>> linux/scripts/recordmcount.[ch] > >>>>> > >>>>> It appears to be triggered when a compiler update causes code to be > >>>>> rearranged. The problem has been reported before in various forums, > >>>>> but in particular I found this reference: > >>>>> > >>>>> https://lore.kernel.org/lkml/20201204165742.3815221-2-arnd at kernel.org/ > >>>>> > >>>>> The point of which to me at least is that this is a kernel issue rather than > >>>>> a compiler issue. Ie there must be some weak symbols in kexec_file.o file > >>>>> which need to be moved elsewhere. > >>>> > >>>>It could be arch_kexec_kernel_verify_sig() in kernel/kexec_file.c which > >>>>is __weak, but not implemented in any ARCH. If true, this has been > >>>>pointed out by Eric in one patch thread from Coiby. > >>>> > >>>>[PATCH v3 1/3] kexec: clean up arch_kexec_kernel_verify_sig > >>>>http://lkml.kernel.org/r/20211018083137.338757-2-coxu at redhat.com > >>>> > >>>>Maybe Coiby can fetch above config file and run the test to check. > >>> > >>>"[PATCH v3 1/3] kexec: clean up arch_kexec_kernel_verify_sig" alone > >>>would fix the error. If I turn arch_kexec_apply_relocations{_add,} into > > > >Sorry I meant "alone won't fix the error". > > > >>>static function, the error would be gone. As attached is the patch would > >>>make this error disappear. > >>> > >> > >>Thank you! I can confirm the attached patch fixes the problem. > >> > >> > >>Veronika > >> > >>>However, s390 and x86 have its own implementation of > >>>arch_kexec_apply_relocations_add. This makes it looks like to be gcc's > >>>issue. > > > >Based on the above point and further investigation, I think the root cause is > >find_secsym_ndx in linux/scripts/recordmcount.h, > > /* > > * Find a symbol in the given section, to be used as the base for relocating > > * the table of offsets of calls to mcount. A local or global symbol suffices, > > * but avoid a Weak symbol because it may be overridden; the change in value > > * would invalidate the relocations of the offsets of the calls to mcount. > > * Often the found symbol will be the unnamed local symbol generated by > > * GNU 'as' for the start of each section. For example: > > * Num: Value Size Type Bind Vis Ndx Name > > * 2: 00000000 0 SECTION LOCAL DEFAULT 1 > > */ > > static int find_secsym_ndx(unsigned const txtndx, > > char const *const txtname, > > uint_t *const recvalp, > > unsigned int *sym_index, > > Elf_Shdr const *const symhdr, > > Elf32_Word const *symtab, > > Elf32_Word const *symtab_shndx, > > Elf_Ehdr const *const ehdr) > > { > > ... > > if (txtndx == get_symindex(symp, symtab, symtab_shndx) > > /* avoid STB_WEAK */ > > > > fprintf(stderr, "Cannot find symbol for section %u: %s.\n", > > txtndx, txtname); > > > >This function prints the above warning after failing to find > >arch_kexec_kernel_verify_sig or arch_kexec_apply_relocations{_add,} in > >section 11: .text.unlikely. because it ignores the weak symbol and ppc64le > >doesn't its arch implementations of these functions. I'll see if I can fix > >it in linux/scripts/recordmcount.h. > > After digging deeper into linux/scripts/recordmcount.h, I think this > issue can be either fixed in the compiler or recordmcount. So I fild two bugs > - gcc: https://bugzilla.redhat.com/show_bug.cgi?id=2059838 Hi, I have also opened a BZ for gcc some time ago and that is where I was redirected to this mailing list, linking it here if it helps: https://bugzilla.redhat.com/show_bug.cgi?id=2022470 Veronika > - linux/scripts/recordmcount.h: https://bugzilla.redhat.com/show_bug.cgi?id=2059842 > > > > >>> > >>> > >>>> > >>>>Thanks > >>>>Baoquan > >>>> > >>> > >>>-- > >>>Best regards, > >>>Coiby > >> > > > >-- > >Best regards, > >Coiby > > -- > Best regards, > Coiby > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Compile error ppc64le: Cannot find symbol for section 11: .text.unlikely. 2022-03-02 10:52 ` Veronika Kabatova @ 2022-03-03 0:49 ` Coiby Xu 0 siblings, 0 replies; 9+ messages in thread From: Coiby Xu @ 2022-03-03 0:49 UTC (permalink / raw) To: kexec On Wed, Mar 02, 2022 at 11:52:12AM +0100, Veronika Kabatova wrote: >On Wed, Mar 2, 2022 at 8:50 AM Coiby Xu <coxu@redhat.com> wrote: >> >> On Fri, Feb 25, 2022 at 11:46:41AM +0800, Coiby Xu wrote: >> >On Fri, Dec 03, 2021 at 04:54:19PM +0100, Veronika Kabatova wrote: >> >>On Wed, Dec 1, 2021 at 3:20 AM Coiby Xu <coxu@redhat.com> wrote: >> >>> >> >>>On Wed, Nov 24, 2021 at 09:47:43PM +0800, Baoquan He wrote: >> >>>>On 11/24/21 at 01:47pm, Veronika Kabatova wrote: >> >>>>> Hi, >> >>>>> >> >>>>> for a while we've been seen the following error when compiling >> >>>>> the mainline kernel with gcc 11.2 and binutils 2.37: >> >>>>> >> >>>>> 00:02:32 Cannot find symbol for section 11: .text.unlikely. >> >>>>> 00:02:32 kernel/kexec_file.o: failed >> >>>>> 00:02:32 make[3]: *** [scripts/Makefile.build:287: kernel/kexec_file.o] Error 1 >> >>>>> 00:02:32 make[3]: *** Deleting file 'kernel/kexec_file.o' >> >>>>> 00:02:32 make[2]: *** [Makefile:1846: kernel] Error 2 >> >>>>> 00:02:32 make[2]: *** Waiting for unfinished jobs.... >> >>>>> >> >>>>> The error only happens with ppc64le. I've tested this with cross >> >>>>> compilation, but the only reference to the error I found suggests >> >>>>> the same happens with the native compiles as well: >> >>>>> >> >>>>> https://github.com/groeck/linux-build-test/commit/142cbefbc0d37962c9a6c7f28ee415ecd5fd1e98 >> >>>>> >> >>>>> In case it matters, the config used is the Fedora config with >> >>>>> kselftest options enabled, which you can grab from >> >>>>> >> >>>>> https://gitlab.com/redhat/red-hat-ci-tools/kernel/cki-internal-pipelines/cki-trusted-contributors/-/jobs/1760752896/artifacts/raw/artifacts/kernel-mainline.kernel.org-ppc64le-e4e737bb5c170df6135a127739a9e6148ee3da82.config >> >>>>> >> >>>>> >> >>>>> I've reached out to the Fedora compiler folks and Nick Clifton >> >>>>> suggested this is a problem with the kernel: >> >>>>> >> >>>>> This message comes from the recordmcount tool, which is part of the kernel >> >>>>> sources: >> >>>>> >> >>>>> linux/scripts/recordmcount.[ch] >> >>>>> >> >>>>> It appears to be triggered when a compiler update causes code to be >> >>>>> rearranged. The problem has been reported before in various forums, >> >>>>> but in particular I found this reference: >> >>>>> >> >>>>> https://lore.kernel.org/lkml/20201204165742.3815221-2-arnd at kernel.org/ >> >>>>> >> >>>>> The point of which to me at least is that this is a kernel issue rather than >> >>>>> a compiler issue. Ie there must be some weak symbols in kexec_file.o file >> >>>>> which need to be moved elsewhere. >> >>>> >> >>>>It could be arch_kexec_kernel_verify_sig() in kernel/kexec_file.c which >> >>>>is __weak, but not implemented in any ARCH. If true, this has been >> >>>>pointed out by Eric in one patch thread from Coiby. >> >>>> >> >>>>[PATCH v3 1/3] kexec: clean up arch_kexec_kernel_verify_sig >> >>>>http://lkml.kernel.org/r/20211018083137.338757-2-coxu at redhat.com >> >>>> >> >>>>Maybe Coiby can fetch above config file and run the test to check. >> >>> >> >>>"[PATCH v3 1/3] kexec: clean up arch_kexec_kernel_verify_sig" alone >> >>>would fix the error. If I turn arch_kexec_apply_relocations{_add,} into >> > >> >Sorry I meant "alone won't fix the error". >> > >> >>>static function, the error would be gone. As attached is the patch would >> >>>make this error disappear. >> >>> >> >> >> >>Thank you! I can confirm the attached patch fixes the problem. >> >> >> >> >> >>Veronika >> >> >> >>>However, s390 and x86 have its own implementation of >> >>>arch_kexec_apply_relocations_add. This makes it looks like to be gcc's >> >>>issue. >> > >> >Based on the above point and further investigation, I think the root cause is >> >find_secsym_ndx in linux/scripts/recordmcount.h, >> > /* >> > * Find a symbol in the given section, to be used as the base for relocating >> > * the table of offsets of calls to mcount. A local or global symbol suffices, >> > * but avoid a Weak symbol because it may be overridden; the change in value >> > * would invalidate the relocations of the offsets of the calls to mcount. >> > * Often the found symbol will be the unnamed local symbol generated by >> > * GNU 'as' for the start of each section. For example: >> > * Num: Value Size Type Bind Vis Ndx Name >> > * 2: 00000000 0 SECTION LOCAL DEFAULT 1 >> > */ >> > static int find_secsym_ndx(unsigned const txtndx, >> > char const *const txtname, >> > uint_t *const recvalp, >> > unsigned int *sym_index, >> > Elf_Shdr const *const symhdr, >> > Elf32_Word const *symtab, >> > Elf32_Word const *symtab_shndx, >> > Elf_Ehdr const *const ehdr) >> > { >> > ... >> > if (txtndx == get_symindex(symp, symtab, symtab_shndx) >> > /* avoid STB_WEAK */ >> > >> > fprintf(stderr, "Cannot find symbol for section %u: %s.\n", >> > txtndx, txtname); >> > >> >This function prints the above warning after failing to find >> >arch_kexec_kernel_verify_sig or arch_kexec_apply_relocations{_add,} in >> >section 11: .text.unlikely. because it ignores the weak symbol and ppc64le >> >doesn't its arch implementations of these functions. I'll see if I can fix >> >it in linux/scripts/recordmcount.h. >> >> After digging deeper into linux/scripts/recordmcount.h, I think this >> issue can be either fixed in the compiler or recordmcount. So I fild two bugs >> - gcc: https://bugzilla.redhat.com/show_bug.cgi?id=2059838 > >Hi, > >I have also opened a BZ for gcc some time ago and that is where I >was redirected to this mailing list, linking it here if it helps: > >https://bugzilla.redhat.com/show_bug.cgi?id=2022470 Hi, Thanks for the info. Sorry I didn't notice this bug. But I will use bz2059838 since I already gave almost the decisive evidence showing there is something wrong with Fedora's gcc in bz2059838. > > >Veronika > >> - linux/scripts/recordmcount.h: https://bugzilla.redhat.com/show_bug.cgi?id=2059842 >> >> > >> >>> >> >>> >> >>>> >> >>>>Thanks >> >>>>Baoquan >> >>>> >> >>> >> >>>-- >> >>>Best regards, >> >>>Coiby >> >> >> > >> >-- >> >Best regards, >> >Coiby >> >> -- >> Best regards, >> Coiby >> > -- Best regards, Coiby ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-03-03 0:49 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-11-24 12:47 Compile error ppc64le: Cannot find symbol for section 11: .text.unlikely Veronika Kabatova 2021-11-24 13:47 ` Baoquan He 2021-12-01 2:19 ` Coiby Xu 2021-12-01 2:26 ` Coiby Xu 2021-12-03 15:54 ` Veronika Kabatova 2022-02-25 3:46 ` Coiby Xu 2022-03-02 7:46 ` Coiby Xu 2022-03-02 10:52 ` Veronika Kabatova 2022-03-03 0:49 ` Coiby Xu
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.