All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fangrui Song <maskray@google.com>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: jpoimboe@redhat.com, peterz@infradead.org,
	clang-built-linux@googlegroups.com,
	Nathan Chancellor <natechancellor@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] objtool: ignore .L prefixed local symbols
Date: Thu, 13 Feb 2020 11:20:55 -0800	[thread overview]
Message-ID: <20200213192055.23kn5pp3s6gwxamq@google.com> (raw)
In-Reply-To: <20200213184708.205083-1-ndesaulniers@google.com>

On 2020-02-13, Nick Desaulniers wrote:
>Top of tree LLVM has optimizations related to
>-fno-semantic-interposition to avoid emitting PLT relocations for
>references to symbols located in the same translation unit, where it
>will emit "local symbol" references.
>
>Clang builds fall back on GNU as for assembling, currently. It appears a
>bug in GNU as introduced around 2.31 is keeping around local labels in
>the symbol table, despite the documentation saying:
>
>"Local symbols are defined and used within the assembler, but they are
>normally not saved in object files."

If you can reword the paragraph above mentioning the fact below without being
more verbose, please do that.

If the reference is within the same section which defines the .L symbol,
there is no outstanding relocation. If the reference is outside the
section, there will be an R_X86_64_PLT32 referencing .L

>When objtool searches for a symbol at a given offset, it's finding the
>incorrectly kept .L<symbol>$local symbol that should have been discarded
>by the assembler.
>
>A patch for GNU as has been authored.  For now, objtool should not treat
>local symbols as the expected symbol for a given offset when iterating
>the symbol table.

Agree. binutils 2.31~2.34 will be affected. objtool has to work around
the existing releases.

>commit 644592d32837 ("objtool: Fail the kernel build on fatal errors")
>exposed this issue.
>
>Link: https://github.com/ClangBuiltLinux/linux/issues/872
>Link: https://sourceware.org/binutils/docs/as/Symbol-Names.html#Symbol-Names
>Link: https://sourceware.org/ml/binutils/2020-02/msg00243.html
>Link: https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/286292010
>Debugged-by: Nathan Chancellor <natechancellor@gmail.com>
>Debugged-by: Fangrui Song <maskray@google.com>
>Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
>Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
>---
>Build tested allyesconfig with ToT Clang and GCC 9.2.1.
>Boot tested defconfig with ToT Clang and GCC 9.2.1.
>
> tools/objtool/elf.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
>index edba4745f25a..9c1e3cc928b0 100644
>--- a/tools/objtool/elf.c
>+++ b/tools/objtool/elf.c
>@@ -63,7 +63,8 @@ struct symbol *find_symbol_by_offset(struct section *sec, unsigned long offset)
>
> 	list_for_each_entry(sym, &sec->symbol_list, list)
> 		if (sym->type != STT_SECTION &&
>-		    sym->offset == offset)
>+		    sym->offset == offset &&
>+		    strstr(sym->name, ".L") != sym->name)

!strncmp(sym->name, ".L", 2)

.L in the middle of a symbol name may be rare, though.

> 			return sym;
>
> 	return NULL;
>-- 
>2.25.0.225.g125e21ebc7-goog
>

  reply	other threads:[~2020-02-13 19:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-13 18:47 [PATCH] objtool: ignore .L prefixed local symbols Nick Desaulniers
2020-02-13 19:20 ` Fangrui Song [this message]
2020-02-14  6:16   ` Arvind Sankar
2020-02-14 18:05     ` Fangrui Song
2020-02-14 20:42       ` Arvind Sankar
2020-02-14 22:20         ` Fangrui Song
2020-02-15  0:05           ` Arvind Sankar
2020-02-15  0:34             ` Arvind Sankar
2020-02-13 22:17 ` Josh Poimboeuf
2020-02-13 22:37   ` Fangrui Song
2020-02-13 23:16     ` Josh Poimboeuf
2020-02-13 22:55   ` Nick Desaulniers

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=20200213192055.23kn5pp3s6gwxamq@google.com \
    --to=maskray@google.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=natechancellor@gmail.com \
    --cc=ndesaulniers@google.com \
    --cc=peterz@infradead.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.