[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b1e5e3ea-be4b-5dae-cc0d-34693429d060@loongson.cn>
Date: Thu, 13 Feb 2025 10:20:40 +0800
From: Tiezhu Yang <yangtiezhu@...ngson.cn>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>, loongarch@...ts.linux.dev,
linux-kernel@...r.kernel.org, Nathan Chancellor <nathan@...nel.org>,
llvm@...ts.linux.dev
Subject: Re: [PATCH] compiler.h: Specify correct attribute for
.rodata..c_jump_table
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@...r.kernel.org # 6.9+
>> Signed-off-by: Tiezhu Yang <yangtiezhu@...ngson.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
Powered by blists - more mailing lists