All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: "Fāng-ruì Sòng" <maskray@google.com>
Cc: "Nick Desaulniers" <ndesaulniers@google.com>,
	"Josh Poimboeuf" <jpoimboe@redhat.com>,
	lma@semihalf.com, "Guenter Roeck" <groeck@google.com>,
	"Juergen Gross" <jgross@suse.com>,
	lb@semihalf.com, LKML <linux-kernel@vger.kernel.org>,
	mbenes@suse.com, "Radosław Biernacki" <rad@semihalf.com>,
	upstream@semihalf.com,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	"Nathan Chancellor" <nathan@kernel.org>,
	"Sami Tolvanen" <samitolvanen@google.com>
Subject: Re: [PATCH v3 16/16] objtool,x86: Rewrite retpoline thunk calls
Date: Mon, 7 Jun 2021 11:45:58 +0200	[thread overview]
Message-ID: <YL3q1qFO9QIRL/BA@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <YL3lQ5QdNV2qwLR/@hirez.programming.kicks-ass.net>

On Mon, Jun 07, 2021 at 11:22:11AM +0200, Peter Zijlstra wrote:
> On Mon, Jun 07, 2021 at 09:56:48AM +0200, Peter Zijlstra wrote:
> > On Sat, Jun 05, 2021 at 06:58:39PM -0700, Fāng-ruì Sòng wrote:
> > > On Sat, Jun 5, 2021 at 3:39 AM Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > > > I think you've absolutely nailed it; but would you have more information
> > > > or a code reference to what you're speaking about? My complete ELF
> > > > and libelf knowledge is very limited and as demonstrated here, I'm not
> > > > at all sure how all that extended index stuff is supposed to work.
> > > 
> > > The section index field of an Elf{32,64}_Sym (st_shndx) is 16-bit, so
> > > it cannot represent a section index greater than 0xffff.
> > > ELF actually reserves values in 0xff00~0xff00 for other purposes, so
> > > st_shndx cannot represent a section whose index is greater or equal to
> > > 0xff00.
> > 
> > Right, that's about as far as I got, but never could find details on how
> > the extension worked in detail, and I clearly muddled it :/
> 
> OK, so I'm all confused again...
> 
> So a .symtab entry has:
> 
> 	st_name  -- strtab offset for the name string
> 	st_value -- where this symbol lives
> 	st_size  -- size of symbol in bytes
> 	st_shndx -- section index to interpret the @st_value above
> 	st_info  -- type+bind
> 	st_other -- visibility
> 
> The thing is, we're adding UNDEF symbols, for the linker to resolve.
> UNDEF has:
> 
> 	st_value := 0
> 	st_size  := 0
> 	st_shndx := 0
> 	st_info  := GLOBAL + NOTYPE
> 	st_other := 0
> 
> Per that, sh_shndx isn't >= SHN_LORESERVE, and I figured we all good.
> 
> 
> Is the problem that .symtab_shndx is expected to contain the exact same
> number of entries as .symtab? And I'm adding to .symtab and not to
> .symtab_shndx, hence getting them out of sync?
> 
> Let me try adding 0s to .symtab_shndx. See if that makes readelf
> happier.

That does indeed seem to do the trick. Bit daft if you ask me, anybody
reading that file ought to have a handy bucket of 0s available, but
whatever.

---
 tools/objtool/elf.c | 25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 743c2e9d0f56..41bca1d13d8e 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -717,7 +717,7 @@ static int elf_add_string(struct elf *elf, struct section *strtab, char *str)
 
 struct symbol *elf_create_undef_symbol(struct elf *elf, const char *name)
 {
-	struct section *symtab;
+	struct section *symtab, *symtab_shndx;
 	struct symbol *sym;
 	Elf_Data *data;
 	Elf_Scn *s;
@@ -769,6 +769,29 @@ struct symbol *elf_create_undef_symbol(struct elf *elf, const char *name)
 	symtab->len += data->d_size;
 	symtab->changed = true;
 
+	symtab_shndx = find_section_by_name(elf, ".symtab_shndx");
+	if (symtab_shndx) {
+		s = elf_getscn(elf->elf, symtab_shndx->idx);
+		if (!s) {
+			WARN_ELF("elf_getscn");
+			return NULL;
+		}
+
+		data = elf_newdata(s);
+		if (!data) {
+			WARN_ELF("elf_newdata");
+			return NULL;
+		}
+
+		data->d_buf = &sym->sym.st_size; /* conveniently 0 */
+		data->d_size = sizeof(Elf32_Word);
+		data->d_align = 4;
+		data->d_type = ELF_T_WORD;
+
+		symtab_shndx->len += 4;
+		symtab_shndx->changed = true;
+	}
+
 	sym->sec = find_section_by_index(elf, 0);
 
 	elf_add_symbol(elf, sym);

  reply	other threads:[~2021-06-07  9:46 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-26 15:11 [PATCH v3 00/16] x86,objtool: Optimize !RETPOLINE Peter Zijlstra
2021-03-26 15:12 ` [PATCH v3 01/16] x86: Add insn_decode_kernel() Peter Zijlstra
2021-04-01 15:08   ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2021-03-26 15:12 ` [PATCH v3 02/16] x86/alternatives: Optimize optimize_nops() Peter Zijlstra
2021-04-01 15:08   ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2021-04-03 11:11   ` tip-bot2 for Peter Zijlstra
2021-03-26 15:12 ` [PATCH v3 03/16] x86/retpoline: Simplify retpolines Peter Zijlstra
2021-04-01 15:08   ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2021-04-03 11:10   ` tip-bot2 for Peter Zijlstra
2021-04-06  8:56     ` David Laight
2021-03-26 15:12 ` [PATCH v3 04/16] objtool: Correctly handle retpoline thunk calls Peter Zijlstra
2021-04-01 15:08   ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2021-04-03 11:10   ` tip-bot2 for Peter Zijlstra
2021-03-26 15:12 ` [PATCH v3 05/16] objtool: Per arch retpoline naming Peter Zijlstra
2021-04-01 15:08   ` [tip: x86/core] objtool: Handle per " tip-bot2 for Peter Zijlstra
2021-04-03 11:10   ` tip-bot2 for Peter Zijlstra
2021-03-26 15:12 ` [PATCH v3 06/16] objtool: Fix static_call list generation Peter Zijlstra
2021-04-01 15:08   ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2021-04-03 11:10   ` tip-bot2 for Peter Zijlstra
2021-03-26 15:12 ` [PATCH v3 07/16] objtool: Rework rebuild_reloc logic Peter Zijlstra
2021-04-01 15:08   ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2021-04-03 11:10   ` [tip: x86/core] objtool: Rework the elf_rebuild_reloc_section() logic tip-bot2 for Peter Zijlstra
2021-03-26 15:12 ` [PATCH v3 08/16] objtool: Add elf_create_reloc() helper Peter Zijlstra
2021-04-01 15:08   ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2021-04-03 11:10   ` tip-bot2 for Peter Zijlstra
2021-03-26 15:12 ` [PATCH v3 09/16] objtool: Implicitly create reloc sections Peter Zijlstra
2021-04-01 15:08   ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2021-04-03 11:10   ` [tip: x86/core] objtool: Create reloc sections implicitly tip-bot2 for Peter Zijlstra
2021-03-26 15:12 ` [PATCH v3 10/16] objtool: Extract elf_strtab_concat() Peter Zijlstra
2021-04-01 15:08   ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2021-04-03 11:10   ` tip-bot2 for Peter Zijlstra
2021-03-26 15:12 ` [PATCH v3 11/16] objtool: Extract elf_symbol_add() Peter Zijlstra
2021-04-01 15:08   ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2021-04-03 11:10   ` tip-bot2 for Peter Zijlstra
2021-03-26 15:12 ` [PATCH v3 12/16] objtool: Add elf_create_undef_symbol() Peter Zijlstra
2021-04-01 15:08   ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2021-04-03 11:10   ` tip-bot2 for Peter Zijlstra
2021-03-26 15:12 ` [PATCH v3 13/16] objtool: Keep track of retpoline call sites Peter Zijlstra
2021-04-01 15:08   ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2021-04-03 11:10   ` tip-bot2 for Peter Zijlstra
2021-03-26 15:12 ` [PATCH v3 14/16] objtool: Cache instruction relocs Peter Zijlstra
2021-04-01 15:08   ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2021-04-03 11:10   ` tip-bot2 for Peter Zijlstra
2021-03-26 15:12 ` [PATCH v3 15/16] objtool: Skip magical retpoline .altinstr_replacement Peter Zijlstra
2021-04-01 15:08   ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2021-04-03 11:10   ` tip-bot2 for Peter Zijlstra
2021-03-26 15:12 ` [PATCH v3 16/16] objtool,x86: Rewrite retpoline thunk calls Peter Zijlstra
2021-03-29 16:38   ` Josh Poimboeuf
2021-06-02 15:51     ` Lukasz Majczak
2021-06-02 16:56       ` Peter Zijlstra
2021-06-02 17:10         ` Peter Zijlstra
2021-06-02 20:43       ` Josh Poimboeuf
2021-06-04 20:50       ` Nick Desaulniers
2021-06-04 23:27         ` Nick Desaulniers
2021-06-04 23:50           ` Fangrui Song
2021-06-05 10:38             ` Peter Zijlstra
2021-06-06  1:58               ` Fāng-ruì Sòng
2021-06-07  7:56                 ` Peter Zijlstra
2021-06-07  9:22                   ` Peter Zijlstra
2021-06-07  9:45                     ` Peter Zijlstra [this message]
2021-06-07 17:23                       ` Fāng-ruì Sòng
2021-06-07 18:25                         ` Peter Zijlstra
2021-06-07 20:54                       ` Nick Desaulniers
2021-06-08  9:56                         ` Peter Zijlstra
2021-06-08 16:58                         ` Nathan Chancellor
2021-06-08 17:22                           ` Peter Zijlstra
2021-06-08 17:29                             ` Nathan Chancellor
2021-06-08 18:17                               ` Peter Zijlstra
2021-06-08 18:49                                 ` Nathan Chancellor
2021-06-09  7:11                                   ` Lukasz Majczak
2021-06-09  7:20                                     ` Peter Zijlstra
2021-06-09 12:23                                       ` Lukasz Majczak
2021-06-09 15:08                                         ` Peter Zijlstra
2021-06-09 15:11                                           ` Peter Zijlstra
2021-06-09 15:56                                           ` Nathan Chancellor
2021-06-08 18:18                               ` Nick Desaulniers
2021-06-07 18:19                 ` Peter Zijlstra
2021-06-07 18:27                   ` Fāng-ruì Sòng
2021-06-07 18:47                     ` Peter Zijlstra
2021-04-01 15:08   ` [tip: x86/core] objtool/x86: " tip-bot2 for Peter Zijlstra
2021-04-03 11:10   ` tip-bot2 for Peter Zijlstra
2021-03-30 15:02 ` [PATCH v3 00/16] x86,objtool: Optimize !RETPOLINE Miroslav Benes

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=YL3q1qFO9QIRL/BA@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=clang-built-linux@googlegroups.com \
    --cc=groeck@google.com \
    --cc=jgross@suse.com \
    --cc=jpoimboe@redhat.com \
    --cc=lb@semihalf.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lma@semihalf.com \
    --cc=maskray@google.com \
    --cc=mbenes@suse.com \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=rad@semihalf.com \
    --cc=samitolvanen@google.com \
    --cc=upstream@semihalf.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.