From: Peter Zijlstra <peterz@infradead.org>
To: Youling Tang <tangyouling@loongson.cn>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
Huacai Chen <chenhuacai@kernel.org>,
madvenka@linux.microsoft.com, chenzhongjin@huawei.com,
WANG Xuerui <kernel@xen0n.name>, Xi Ruoyao <xry111@xry111.site>,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
loongarch@lists.linux.dev, tangyouling00@gmail.com,
youling.tang@outlook.com, Jinyang He <hejinyang@loongson.cn>
Subject: Re: [RFC PATCH v1 13/23] objtool: Add next member in struct reloc
Date: Tue, 20 Jun 2023 10:57:46 +0200 [thread overview]
Message-ID: <20230620085746.GY4253@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <1687247415-32057-4-git-send-email-tangyouling@loongson.cn>
On Tue, Jun 20, 2023 at 03:50:09PM +0800, Youling Tang wrote:
> In LoongArch, there may be multiple relocation information in one location,
> so the next member is added to handle this situation.
So Josh did a shrink on struct reloc because there are too many of them;
ideally we find another way to link them for the case where it is
needed.
>
> The following warning appears when the next member is not added,
> warning: objtool: unexpected relocation symbol type in .rela.discard.unreachable
>
> Relocation section '.rela.discard.unreachable' at offset 0x1a58 contains 4 entries:
> Offset Info Type Symbol's Value Symbol's Name + Addend
> 0000000000000000 0000000200000032 R_LARCH_ADD32 0000000000000000 .text + 354
> 0000000000000000 0000000900000037 R_LARCH_SUB32 0000000000000000 L0^A + 0
>
> Co-developed-by: Jinyang He <hejinyang@loongson.cn>
> Signed-off-by: Jinyang He <hejinyang@loongson.cn>
> Signed-off-by: Youling Tang <tangyouling@loongson.cn>
> ---
> tools/objtool/elf.c | 11 ++++++++++-
> tools/objtool/include/objtool/elf.h | 1 +
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
> index 6806ce01d933..d345300d269b 100644
> --- a/tools/objtool/elf.c
> +++ b/tools/objtool/elf.c
> @@ -895,7 +895,7 @@ static int read_relocs(struct elf *elf)
> {
> unsigned long nr_reloc, max_reloc = 0, tot_reloc = 0;
> struct section *sec;
> - struct reloc *reloc;
> + struct reloc *reloc, *next_reloc;
> unsigned int symndx;
> struct symbol *sym;
> int i;
> @@ -915,6 +915,7 @@ static int read_relocs(struct elf *elf)
> return -1;
> }
>
> + next_reloc = NULL;
> sec->base->reloc = sec;
>
> nr_reloc = 0;
> @@ -946,6 +947,14 @@ static int read_relocs(struct elf *elf)
> return -1;
> }
>
> + if (next_reloc && reloc->offset == next_reloc->offset) {
> + next_reloc->next = reloc;
> + next_reloc = reloc;
> + continue;
> + }
> +
> + next_reloc = reloc;
This seems to rely on 'linked' reloc being adjecent in the ELF tables;
is this required by the LoongArch ELF spec? If not, you really should
not rely on it.
> +
> list_add_tail(&reloc->sym_reloc_entry, &sym->reloc_list);
> list_add_tail(&reloc->list, &sec->reloc_list);
> elf_hash_add(reloc, &reloc->hash, reloc_hash(reloc));
> diff --git a/tools/objtool/include/objtool/elf.h b/tools/objtool/include/objtool/elf.h
> index ad0024da262b..7877298fe401 100644
> --- a/tools/objtool/include/objtool/elf.h
> +++ b/tools/objtool/include/objtool/elf.h
> @@ -68,6 +68,7 @@ struct symbol {
> struct reloc {
> struct list_head list;
> struct hlist_node hash;
> + struct reloc *next;
> union {
> GElf_Rela rela;
> GElf_Rel rel;
> --
> 2.39.2
>
next prev parent reply other threads:[~2023-06-20 8:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-20 7:50 [RFC PATCH v1 10/23] objtool: LoongArch: Implement decoder Youling Tang
2023-06-20 7:50 ` [RFC PATCH v1 11/23] objtool: Add annotate_reachable() for objtools Youling Tang
2023-06-20 7:50 ` [RFC PATCH v1 12/23] LoongArch: bug: Add reachable annotation to warning macros Youling Tang
2023-06-20 7:50 ` [RFC PATCH v1 13/23] objtool: Add next member in struct reloc Youling Tang
2023-06-20 8:57 ` Peter Zijlstra [this message]
2023-06-20 7:50 ` [RFC PATCH v1 14/23] objtool: Add orc_print_dump() package Youling Tang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230620085746.GY4253@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=chenhuacai@kernel.org \
--cc=chenzhongjin@huawei.com \
--cc=hejinyang@loongson.cn \
--cc=jpoimboe@kernel.org \
--cc=kernel@xen0n.name \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=madvenka@linux.microsoft.com \
--cc=tangyouling00@gmail.com \
--cc=tangyouling@loongson.cn \
--cc=xry111@xry111.site \
--cc=youling.tang@outlook.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).