linux-kernel - Re: [PATCH v5 03/10] objtool: Handle PC relative relocation type

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <91b079a1-4f0f-8017-cdae-f6e2729d72a3@loongson.cn>
Date: Thu, 12 Dec 2024 09:34:24 +0800
From: Tiezhu Yang <yangtiezhu@...ngson.cn>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Huacai Chen <chenhuacai@...nel.org>, Peter Zijlstra
 <peterz@...radead.org>, loongarch@...ts.linux.dev,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 03/10] objtool: Handle PC relative relocation type

On 12/12/2024 08:35 AM, Josh Poimboeuf wrote:
> On Wed, Dec 11, 2024 at 11:16:33AM +0800, Tiezhu Yang wrote:
>> When compiling on LoongArch, there are some PC relative relocation types
>> for rodata, it needs to calculate the symbol offset with "S + A - PC" in
>> this case according to the spec of "ELF for the LoongArch Architecture",
>> the "PC" is the index of each jump table which is equal with the value
>> of reloc_offset(reloc) - reloc_offset(table).
>>
>> I will add the above description to the commit message to make it clear.
>
> I understand how PC-relative addressing works.
>
> The oddity here is that "PC" is the jump table's base address rather
> than the entry address.

If there is only one jump table in the rodata, the "PC" is the entry
address which is equal with the value of reloc_offset(reloc), at this
time, reloc_offset(table) is 0.

If there are many jump tables in the rodata, the "PC" is the offset
of the jump table's base address which is equal with the value of 
reloc_offset(reloc) - reloc_offset(table).

> That has nothing to do with the ELF spec or
> even how R_LARCH_32_PCREL is implemented.  Rather it seems to be a quirk
> related to how loongarch jump table code expects the entries to be.
>
> So the arch_adjust_offset() name seems wrong, as this is specific to
> the jump table implementation, rather than relocs in general.
>
> Instead call it arch_jump_table_sym_offset()?

OK, will modify it and add the above description to the commit message
to make it clear.

Thanks,
Tiezhu