From: Peter Zijlstra <peterz@infradead.org>
To: Fangrui Song <maskray@google.com>
Cc: x86@kernel.org, Josh Poimboeuf <jpoimboe@kernel.org>,
linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
Nick Desaulniers <ndesaulniers@google.com>
Subject: Re: [PATCH] x86/speculation, objtool: Use absolute relocations for annotations
Date: Thu, 21 Sep 2023 17:35:37 +0200 [thread overview]
Message-ID: <20230921153537.GG14803@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <CAFP8O3+_8H+fetuoqwwcfqJLNtYmpsWZhY2arD7HMuPmcN+X_g@mail.gmail.com>
On Thu, Sep 21, 2023 at 12:58:13AM -0700, Fangrui Song wrote:
> On Thu, Sep 21, 2023 at 12:26 AM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Tue, Sep 19, 2023 at 05:17:28PM -0700, Fangrui Song wrote:
> > > .discard.retpoline_safe sections do not have the SHF_ALLOC flag. These
> > > sections referencing text sections' STT_SECTION symbols with PC-relative
> > > relocations like R_386_PC32 [0] is conceptually not suitable. Newer
> > > LLD will report warnings for REL relocations even for relocatable links
> > > [1].
> > >
> > > ld.lld: warning: vmlinux.a(drivers/i2c/busses/i2c-i801.o):(.discard.retpoline_safe+0x120): has non-ABS relocation R_386_PC32 against symbol ''
> >
> > What, why ?!? Please explain more.
>
> This can be read as a pedantic warning from the linker.
>
> A location relocated by an R_386_PC32 relocation in
> .discard.retpoline_safe records an offset from the current location
> (non-allocable) to an text symbol.
> This offset is conceptually not suitable: in the ELF object file
> format's model, the non-SHF_ALLOC section is not part of the memory
> image, so
> we cannot say that the offset from the non-memory thing to a text
> symbol is a fixed value.
Bah, so why has this worked at all then? Clearly the linkers aren't very
strict about things.
Anyway, I think what we want is to just mark the section SHF_ALLOC. The
reason is that one of the plans we have is to collapse all the different
annotations into a single section and then have something like:
struct objtoo_annotation {
s32 location;
u32 type;
}
So that we can easily extend the annotations and don't need to add
yet-another-section-reader-function to objtool.
This is just one of the things we've not gotten around to yet. But as
is, we have:
.discard.unreachable
.discard.reachable
.discard.func_stack_frame_non_standard
.discard.ignore_alts
.discard.unwind_hints
.discard.noendbr
.discard.retpoline_safe
.discard.instr_end
.discard.instr_begin
.discard.validate_unret
.discard.intra_function_calls
And with the exception of unwind_hints, they're all just trivial
location things.
The very last thing we need is yet more of that.
If we were to use absolute things, we get 12 byte entries and while that
probably wouldn't spell the end of the world, why make thing larger than
they have to be.
After all, its not like any of this actually survives the final link.
next prev parent reply other threads:[~2023-09-21 18:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-20 0:17 [PATCH] x86/speculation, objtool: Use absolute relocations for annotations Fangrui Song
2023-09-21 7:12 ` [tip: objtool/core] " tip-bot2 for Fangrui Song
2023-09-21 7:27 ` Peter Zijlstra
2023-09-21 8:03 ` Ingo Molnar
2023-09-21 7:26 ` [PATCH] " Peter Zijlstra
2023-09-21 7:58 ` Fangrui Song
2023-09-21 15:35 ` Peter Zijlstra [this message]
2023-09-21 16:26 ` Fangrui Song
2023-09-21 17:19 ` Peter Zijlstra
2023-09-21 17:36 ` Fangrui Song
2023-09-21 19:22 ` Peter Zijlstra
2023-09-21 19:31 ` Peter Zijlstra
2023-09-21 20:07 ` Fangrui Song
2023-09-21 20:18 ` Peter Zijlstra
2023-09-22 9:51 ` [tip: objtool/core] " tip-bot2 for Fangrui Song
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=20230921153537.GG14803@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=maskray@google.com \
--cc=ndesaulniers@google.com \
--cc=x86@kernel.org \
/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