include/linux/compiler.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Currently, there is an assembler message when generating kernel/bpf/core.o
under CONFIG_OBJTOOL with LoongArch compiler toolchain:
Warning: setting incorrect section attributes for .rodata..c_jump_table
This is because the section ".rodata..c_jump_table" should be readonly,
but there is a "W" (writable) part of the flags:
$ readelf -S kernel/bpf/core.o | grep -A 1 "rodata..c"
[34] .rodata..c_j[...] PROGBITS 0000000000000000 0000d2e0
0000000000000800 0000000000000000 WA 0 0 8
There is no above issue on x86 due to the generated section flag is only
"A" (allocatable). In order to silence the warning on LoongArch, specify
the attribute like ".rodata..c_jump_table,\"a\",@progbits #" explicitly,
then the section attribute of ".rodata..c_jump_table" must be readonly
in the kernel/bpf/core.o file.
Before:
$ objdump -h kernel/bpf/core.o | grep -A 1 "rodata..c"
21 .rodata..c_jump_table 00000800 0000000000000000 0000000000000000 0000d2e0 2**3
CONTENTS, ALLOC, LOAD, RELOC, DATA
After:
$ objdump -h kernel/bpf/core.o | grep -A 1 "rodata..c"
21 .rodata..c_jump_table 00000800 0000000000000000 0000000000000000 0000d2e0 2**3
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
By the way, AFAICT, maybe the root cause is related with the different
compiler behavior of various archs, so to some extent this change is a
workaround for LoongArch, and also there is no effect for x86 which is
the only port supported by objtool before LoongArch with this patch.
Cc: stable@vger.kernel.org # 6.9+
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---
include/linux/compiler.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index ec55bcce4146..4d4e23b6e3e7 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -133,7 +133,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
#define annotate_unreachable() __annotate_unreachable(__COUNTER__)
/* Annotate a C jump table to allow objtool to follow the code flow */
-#define __annotate_jump_table __section(".rodata..c_jump_table")
+#define __annotate_jump_table __section(".rodata..c_jump_table,\"a\",@progbits #")
#else /* !CONFIG_OBJTOOL */
#define annotate_reachable()
--
2.42.0On Tue, Sep 24, 2024 at 02:27:10PM +0800, Tiezhu Yang wrote:
> Currently, there is an assembler message when generating kernel/bpf/core.o
> under CONFIG_OBJTOOL with LoongArch compiler toolchain:
>
> Warning: setting incorrect section attributes for .rodata..c_jump_table
>
> This is because the section ".rodata..c_jump_table" should be readonly,
> but there is a "W" (writable) part of the flags:
>
> $ readelf -S kernel/bpf/core.o | grep -A 1 "rodata..c"
> [34] .rodata..c_j[...] PROGBITS 0000000000000000 0000d2e0
> 0000000000000800 0000000000000000 WA 0 0 8
>
> There is no above issue on x86 due to the generated section flag is only
> "A" (allocatable). In order to silence the warning on LoongArch, specify
> the attribute like ".rodata..c_jump_table,\"a\",@progbits #" explicitly,
> then the section attribute of ".rodata..c_jump_table" must be readonly
> in the kernel/bpf/core.o file.
>
> Before:
>
> $ objdump -h kernel/bpf/core.o | grep -A 1 "rodata..c"
> 21 .rodata..c_jump_table 00000800 0000000000000000 0000000000000000 0000d2e0 2**3
> CONTENTS, ALLOC, LOAD, RELOC, DATA
>
> After:
>
> $ objdump -h kernel/bpf/core.o | grep -A 1 "rodata..c"
> 21 .rodata..c_jump_table 00000800 0000000000000000 0000000000000000 0000d2e0 2**3
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
>
> By the way, AFAICT, maybe the root cause is related with the different
> compiler behavior of various archs, so to some extent this change is a
> workaround for LoongArch, and also there is no effect for x86 which is
> the only port supported by objtool before LoongArch with this patch.
Right, this sounds like a bug in the GNU assembler. It should default
to the same section flags regardless of arch.
>
> Cc: stable@vger.kernel.org # 6.9+
> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> ---
> include/linux/compiler.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index ec55bcce4146..4d4e23b6e3e7 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -133,7 +133,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
> #define annotate_unreachable() __annotate_unreachable(__COUNTER__)
>
> /* Annotate a C jump table to allow objtool to follow the code flow */
> -#define __annotate_jump_table __section(".rodata..c_jump_table")
> +#define __annotate_jump_table __section(".rodata..c_jump_table,\"a\",@progbits #")
This caused a regression, this hack apparently doesn't work with Clang:
$ readelf -WS kernel/bpf/core.o | grep c_jump_table
[43] .rodata..c_jump_table,"a",@progbits # PROGBITS 0000000000000000 00d610 000800 00 A 0 0 16
Notice the section name is literally:
.rodata..c_jump_table,"a",@progbits #
--
Josh
On 02/13/2025 01:50 AM, Josh Poimboeuf wrote:
> On Tue, Sep 24, 2024 at 02:27:10PM +0800, Tiezhu Yang wrote:
>> Currently, there is an assembler message when generating kernel/bpf/core.o
>> under CONFIG_OBJTOOL with LoongArch compiler toolchain:
>>
>> Warning: setting incorrect section attributes for .rodata..c_jump_table
>>
>> This is because the section ".rodata..c_jump_table" should be readonly,
>> but there is a "W" (writable) part of the flags:
>>
>> $ readelf -S kernel/bpf/core.o | grep -A 1 "rodata..c"
>> [34] .rodata..c_j[...] PROGBITS 0000000000000000 0000d2e0
>> 0000000000000800 0000000000000000 WA 0 0 8
>>
>> There is no above issue on x86 due to the generated section flag is only
>> "A" (allocatable). In order to silence the warning on LoongArch, specify
>> the attribute like ".rodata..c_jump_table,\"a\",@progbits #" explicitly,
>> then the section attribute of ".rodata..c_jump_table" must be readonly
>> in the kernel/bpf/core.o file.
>>
>> Before:
>>
>> $ objdump -h kernel/bpf/core.o | grep -A 1 "rodata..c"
>> 21 .rodata..c_jump_table 00000800 0000000000000000 0000000000000000 0000d2e0 2**3
>> CONTENTS, ALLOC, LOAD, RELOC, DATA
>>
>> After:
>>
>> $ objdump -h kernel/bpf/core.o | grep -A 1 "rodata..c"
>> 21 .rodata..c_jump_table 00000800 0000000000000000 0000000000000000 0000d2e0 2**3
>> CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
>>
>> By the way, AFAICT, maybe the root cause is related with the different
>> compiler behavior of various archs, so to some extent this change is a
>> workaround for LoongArch, and also there is no effect for x86 which is
>> the only port supported by objtool before LoongArch with this patch.
>
> Right, this sounds like a bug in the GNU assembler. It should default
> to the same section flags regardless of arch.
I agree with you.
>
>>
>> Cc: stable@vger.kernel.org # 6.9+
>> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
>> ---
>> include/linux/compiler.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
>> index ec55bcce4146..4d4e23b6e3e7 100644
>> --- a/include/linux/compiler.h
>> +++ b/include/linux/compiler.h
>> @@ -133,7 +133,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
>> #define annotate_unreachable() __annotate_unreachable(__COUNTER__)
>>
>> /* Annotate a C jump table to allow objtool to follow the code flow */
>> -#define __annotate_jump_table __section(".rodata..c_jump_table")
>> +#define __annotate_jump_table __section(".rodata..c_jump_table,\"a\",@progbits #")
>
> This caused a regression, this hack apparently doesn't work with Clang:
>
> $ readelf -WS kernel/bpf/core.o | grep c_jump_table
> [43] .rodata..c_jump_table,"a",@progbits # PROGBITS 0000000000000000 00d610 000800 00 A 0 0 16
>
> Notice the section name is literally:
>
> .rodata..c_jump_table,"a",@progbits #
Yes, I noticed this section name which contains the original name
".rodata..c_jump_table" and the specified attribute compiled with
Clang, it should not contain the specified attribute.
That is strange but seems no effect due to only compare the first
few letters of the section name in objtool.
I will keep digging with the GNU and LLVM compiler developers.
Thanks,
Tiezhu
On Thu, Feb 13, 2025 at 10:20:40AM +0800, Tiezhu Yang wrote:
> On 02/13/2025 01:50 AM, Josh Poimboeuf wrote:
> > > @@ -133,7 +133,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
> > > #define annotate_unreachable() __annotate_unreachable(__COUNTER__)
> > >
> > > /* Annotate a C jump table to allow objtool to follow the code flow */
> > > -#define __annotate_jump_table __section(".rodata..c_jump_table")
> > > +#define __annotate_jump_table __section(".rodata..c_jump_table,\"a\",@progbits #")
> >
> > This caused a regression, this hack apparently doesn't work with Clang:
> >
> > $ readelf -WS kernel/bpf/core.o | grep c_jump_table
> > [43] .rodata..c_jump_table,"a",@progbits # PROGBITS 0000000000000000 00d610 000800 00 A 0 0 16
> >
> > Notice the section name is literally:
> >
> > .rodata..c_jump_table,"a",@progbits #
>
> Yes, I noticed this section name which contains the original name
> ".rodata..c_jump_table" and the specified attribute compiled with
> Clang, it should not contain the specified attribute.
>
> That is strange but seems no effect due to only compare the first
> few letters of the section name in objtool.
It actually does have an effect -- objtool doesn't recognize the BPF C
jump table (see the use of C_JUMP_TABLE_SECTION in
tools/objtool/arch/x86/special.c), resulting in a bogus warning and
missing ORC.
I do have a workaround to use strstarts() instead of strcmp(), I'll be
posting that soon.
> I will keep digging with the GNU and LLVM compiler developers.
Thanks!
--
Josh
On 02/13/2025 10:39 AM, Josh Poimboeuf wrote:
> On Thu, Feb 13, 2025 at 10:20:40AM +0800, Tiezhu Yang wrote:
>> On 02/13/2025 01:50 AM, Josh Poimboeuf wrote:
>>>> @@ -133,7 +133,7 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
>>>> #define annotate_unreachable() __annotate_unreachable(__COUNTER__)
>>>>
>>>> /* Annotate a C jump table to allow objtool to follow the code flow */
>>>> -#define __annotate_jump_table __section(".rodata..c_jump_table")
>>>> +#define __annotate_jump_table __section(".rodata..c_jump_table,\"a\",@progbits #")
>>>
>>> This caused a regression, this hack apparently doesn't work with Clang:
>>>
>>> $ readelf -WS kernel/bpf/core.o | grep c_jump_table
>>> [43] .rodata..c_jump_table,"a",@progbits # PROGBITS 0000000000000000 00d610 000800 00 A 0 0 16
>>>
>>> Notice the section name is literally:
>>>
>>> .rodata..c_jump_table,"a",@progbits #
>>
>> Yes, I noticed this section name which contains the original name
>> ".rodata..c_jump_table" and the specified attribute compiled with
>> Clang, it should not contain the specified attribute.
>>
>> That is strange but seems no effect due to only compare the first
>> few letters of the section name in objtool.
>
> It actually does have an effect -- objtool doesn't recognize the BPF C
> jump table (see the use of C_JUMP_TABLE_SECTION in
> tools/objtool/arch/x86/special.c), resulting in a bogus warning and
> missing ORC.
>
> I do have a workaround to use strstarts() instead of strcmp(), I'll be
> posting that soon.
>
>> I will keep digging with the GNU and LLVM compiler developers.
Specify the attribute like ".rodata..c_jump_table,\"a\",@progbits #"
explicitly works for GNU toolchains, but this hack apparently doesn't
work with Clang, the generated section name is wrong, resulting in a
bogus warning and missing ORC for x86. This is because there is only
one arg for section name in LLVM, even if the so called attribute is
specified, it will be recognized as a whole for section name, so it
is not proper to specify the readonly attribute for the section.
In the top Makefile, there is "-fno-PIE" build flag. For x86, there
is no "-fPIE" build flag in arch/x86/Makefile for 64 bit kernel. But
for LoongArch, there is "-fPIE" build flag in arch/loongarch/Makefile
to override "-fno-PIE" in top Makefile. After some test with GCC and
Clang on x86 and LoongArch, it shows that the generated "W" (writable)
section attribute of the section ".rodata..c_jump_table" is depent on
the compiler option "-fPIE", and then lead to the assembler warning:
"setting incorrect section attributes for .rodata..c_jump_table".
Note that when running the following steps, x86 and LoongArch have the
same result. If compiled with GCC -fPIE, there is assembler warning for
x86 and LoongArch; if compiled with Clang -fPIE, there is no assembler
warning for x86 and LoongArch.
If just drop the prefix ".rodata" of the section name, that is to say,
rename ".rodata..c_jump_table" to ".c_jump_table", there is no assembler
warning for x86 and LoongArch.
Based on the above analysis, in order to avoid changing the behavior of
GNU assembler and silence the GNU assembler warning, is it possible to
rename ".rodata..c_jump_table" to ".c_jump_table"? Or should it do some
changes for GNU assembler?
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/config/obj-elf.c;hb=HEAD#l741
if (match_p->group_name == NULL)
as_warn (_("setting incorrect section attributes for %s"),
name);
(1) Here is the simple test code with the original section name:
$ cat test.c
#define __annotate_jump_table
__attribute__((__section__(".rodata..c_jump_table")))
int main()
{
static const void * const jumptable[256] __annotate_jump_table = {
[0 ... 255] = &&default_label,
};
default_label:
return 0;
}
(2) Here is the build script:
$ cat build.sh
#!/bin/bash
uname -m
echo ""
rm -f *gcc* *clang*
echo "test with gcc fpie"
gcc -fPIE -E test.c -o test_with_gcc_fpie.i
gcc -fPIE -S test_with_gcc_fpie.i -o test_with_gcc_fpie.s
gcc -fPIE -c test_with_gcc_fpie.s -o test_with_gcc_fpie.o
readelf -S test_with_gcc_fpie.o | grep -A 1 "c_j" | head -2
echo ""
echo "test with gcc fnopie"
gcc -fno-PIE -E test.c -o test_with_gcc_fnopie.i
gcc -fno-PIE -S test_with_gcc_fnopie.i -o test_with_gcc_fnopie.s
gcc -fno-PIE -c test_with_gcc_fnopie.s -o test_with_gcc_fnopie.o
readelf -S test_with_gcc_fnopie.o | grep -A 1 "c_j" | head -2
echo ""
echo "test with clang fpie"
clang -fPIE -E test.c -o test_with_clang_fpie.i
clang -fPIE -S test_with_clang_fpie.i -o test_with_clang_fpie.s
clang -fPIE -c test_with_clang_fpie.s -o test_with_clang_fpie.o
readelf -S test_with_clang_fpie.o | grep -A 1 "c_j" | head -2
echo ""
echo "test with clang fnopie"
clang -fno-PIE -E test.c -o test_with_clang_fnopie.i
clang -fno-PIE -S test_with_clang_fnopie.i -o test_with_clang_fnopie.s
clang -fno-PIE -c test_with_clang_fnopie.s -o test_with_clang_fnopie.o
readelf -S test_with_clang_fnopie.o | grep -A 1 "c_j" | head -2
(3) Here is the test result with the original section name:
$ ./build.sh
x86_64
test with gcc fpie
test_with_gcc_fpie.s: Assembler messages:
test_with_gcc_fpie.s:3: Warning: setting incorrect section attributes
for .rodata..c_jump_table
[ 4] .rodata..c_j[...] PROGBITS 0000000000000000 00000060
0000000000000800 0000000000000000 WA 0 0 32
test with gcc fnopie
[ 4] .rodata..c_j[...] PROGBITS 0000000000000000 00000060
0000000000000800 0000000000000000 A 0 0 32
test with clang fpie
[ 3] .rodata..c_j[...] PROGBITS 0000000000000000 00000050
0000000000000800 0000000000000000 WA 0 0 16
test with clang fnopie
[ 3] .rodata..c_j[...] PROGBITS 0000000000000000 00000050
0000000000000800 0000000000000000 A 0 0 16
(4) Here is the simple test code with the modified section name:
$ cat test.c
#define __annotate_jump_table __attribute__((__section__(".c_jump_table")))
int main()
{
static const void * const jumptable[256] __annotate_jump_table = {
[0 ... 255] = &&default_label,
};
default_label:
return 0;
}
(5) Here is the test result with the modified section name:
(note that build.sh is not changed)
$ ./build.sh
x86_64
test with gcc fpie
[ 4] .c_jump_table PROGBITS 0000000000000000 00000060
0000000000000800 0000000000000000 WA 0 0 32
test with gcc fnopie
[ 4] .c_jump_table PROGBITS 0000000000000000 00000060
0000000000000800 0000000000000000 A 0 0 32
test with clang fpie
[ 3] .c_jump_table PROGBITS 0000000000000000 00000050
0000000000000800 0000000000000000 WA 0 0 16
test with clang fnopie
[ 3] .c_jump_table PROGBITS 0000000000000000 00000050
0000000000000800 0000000000000000 A 0 0 16
Thanks,
Tiezhu
On Thu, Feb 13, 2025 at 08:38:22PM +0800, Tiezhu Yang wrote: > Based on the above analysis, in order to avoid changing the behavior of > GNU assembler and silence the GNU assembler warning, is it possible to > rename ".rodata..c_jump_table" to ".c_jump_table"? Yeah, though for the final vmlinux link we'd still need it to end up in .rodata so it remains read-only at runtime. So we'd basically just have to add it to the RO_DATA() macro in include/asm-generic/vmlinux.lds.h. Does it still work if we call it ..rodata.c_jump_table or so? Then we could just add "*(..rodata.*) to RO_DATA(). That would be somewhat less surprising, and would also create a standard way for other code to do the same thing by prefixing with "..rodata.". -- Josh
On 02/14/2025 02:54 AM, Josh Poimboeuf wrote:
> On Thu, Feb 13, 2025 at 08:38:22PM +0800, Tiezhu Yang wrote:
>> Based on the above analysis, in order to avoid changing the behavior of
>> GNU assembler and silence the GNU assembler warning, is it possible to
>> rename ".rodata..c_jump_table" to ".c_jump_table"?
>
> Yeah, though for the final vmlinux link we'd still need it to end up in
> .rodata so it remains read-only at runtime.
>
> So we'd basically just have to add it to the RO_DATA() macro in
> include/asm-generic/vmlinux.lds.h.
>
> Does it still work if we call it ..rodata.c_jump_table or so? Then we
> could just add "*(..rodata.*) to RO_DATA(). That would be somewhat less
> surprising, and would also create a standard way for other code to do
> the same thing by prefixing with "..rodata.".
"..rodata.c_jump_table" works well with GCC and Clang,
there is no assembler warning for GCC and the section
name is normal for Clang.
I have a draft diff, I will do more test and send it
as a formal patch once the other patches are landed
because this patch depends on them.
The code looks something like this:
-- >8 --
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index 02a4adb4a999..0af80d6627fa 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -457,7 +457,7 @@ defined(CONFIG_AUTOFDO_CLANG) ||
defined(CONFIG_PROPELLER_CLANG)
. = ALIGN((align)); \
.rodata : AT(ADDR(.rodata) - LOAD_OFFSET) { \
__start_rodata = .; \
- *(.rodata) *(.rodata.*) \
+ *(.rodata) *(.rodata.*) *(..rodata.*) \
SCHED_DATA \
RO_AFTER_INIT_DATA /* Read only after init */ \
. = ALIGN(8); \
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 200fd3c5bc70..9b56788bf3f1 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -110,7 +110,8 @@ void ftrace_likely_update(struct ftrace_likely_data
*f, int val,
/* Unreachable code */
#ifdef CONFIG_OBJTOOL
/* Annotate a C jump table to allow objtool to follow the code flow */
-#define __annotate_jump_table
__section(".rodata..c_jump_table,\"a\",@progbits #")
+#define __annotate_jump_table __section("..rodata.c_jump_table")
+#endif
#else /* !CONFIG_OBJTOOL */
#define __annotate_jump_table
#endif /* CONFIG_OBJTOOL */
diff --git a/tools/objtool/arch/loongarch/special.c
b/tools/objtool/arch/loongarch/special.c
index 27c6473608f3..d3e10ad3a9bf 100644
--- a/tools/objtool/arch/loongarch/special.c
+++ b/tools/objtool/arch/loongarch/special.c
@@ -131,7 +131,7 @@ static struct reloc
*find_reloc_of_rodata_c_jump_table(struct section *sec,
if (reloc_offset(reloc) > offset)
break;
- if (!strncmp(reloc->sym->sec->name,
".rodata..c_jump_table", 21)) {
+ if (!strncmp(reloc->sym->sec->name,
"..rodata.c_jump_table", 21)) {
*table_size = 0;
return reloc;
}
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 7174dcb7496e..a8b67b4c5726 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -2482,12 +2482,13 @@ static void mark_rodata(struct objtool_file *file)
*
* - .rodata: can contain GCC switch tables
* - .rodata.<func>: same, if -fdata-sections is being used
- * - .rodata..c_jump_table: contains C annotated jump tables
+ * - ..rodata.c_jump_table: contains C annotated jump tables
*
* .rodata.str1.* sections are ignored; they don't contain jump
tables.
*/
for_each_sec(file, sec) {
- if (!strncmp(sec->name, ".rodata", 7) &&
+ if ((!strncmp(sec->name, ".rodata", 7) ||
+ !strncmp(sec->name, "..rodata", 8)) &&
!strstr(sec->name, ".str1.")) {
sec->rodata = true;
found = true;
diff --git a/tools/objtool/include/objtool/special.h
b/tools/objtool/include/objtool/special.h
index e7ee7ffccefd..34acf4ae5fab 100644
--- a/tools/objtool/include/objtool/special.h
+++ b/tools/objtool/include/objtool/special.h
@@ -10,7 +10,7 @@
#include <objtool/check.h>
#include <objtool/elf.h>
-#define C_JUMP_TABLE_SECTION ".rodata..c_jump_table"
+#define C_JUMP_TABLE_SECTION "..rodata.c_jump_table"
struct special_alt {
struct list_head list;
Thanks,
Tiezhu
On Fri, Feb 14, 2025 at 10:23:08AM +0800, Tiezhu Yang wrote: > I have a draft diff, I will do more test and send it > as a formal patch once the other patches are landed > because this patch depends on them. Actually since this is a bug fix, I'm thinking it should be merged in the tip/objtool/urgent branch so it can go in an -rc. Then it should be trivial for me to rebase your patches on top. > The code looks something like this: Looks good to me. nit: loongarch can use the C_JUMP_TABLE_SECTION define. -- Josh
On 02/14/2025 04:44 PM, Josh Poimboeuf wrote:
> On Fri, Feb 14, 2025 at 10:23:08AM +0800, Tiezhu Yang wrote:
>> I have a draft diff, I will do more test and send it
>> as a formal patch once the other patches are landed
>> because this patch depends on them.
>
> Actually since this is a bug fix, I'm thinking it should be merged in
> the tip/objtool/urgent branch so it can go in an -rc. Then it should be
> trivial for me to rebase your patches on top.
OK, I will send a patch based on tip/objtool/urgent branch ASAP.
>> The code looks something like this:
>
> Looks good to me. nit: loongarch can use the C_JUMP_TABLE_SECTION
> define.
Yes, thank you, hope you can amend it when applying my original patch,
maybe like this:
diff --git a/tools/objtool/arch/loongarch/special.c
b/tools/objtool/arch/loongarch/special.c
index 27c6473608f3..e39f86d97002 100644
--- a/tools/objtool/arch/loongarch/special.c
+++ b/tools/objtool/arch/loongarch/special.c
@@ -131,7 +131,7 @@ static struct reloc
*find_reloc_of_rodata_c_jump_table(struct section *sec,
if (reloc_offset(reloc) > offset)
break;
- if (!strncmp(reloc->sym->sec->name,
".rodata..c_jump_table", 21)) {
+ if (!strcmp(reloc->sym->sec->name, C_JUMP_TABLE_SECTION)) {
*table_size = 0;
return reloc;
}
Thanks,
Tiezhu
© 2016 - 2026 Red Hat, Inc.