All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sami Tolvanen <samitolvanen@google.com>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Kees Cook <keescook@chromium.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] objtool: optimize add_dead_ends for split sections
Date: Tue, 21 Apr 2020 15:02:58 -0700	[thread overview]
Message-ID: <20200421220258.GA85573@google.com> (raw)
In-Reply-To: <20200421201305.66y2u473htzcuhfu@treble>

On Tue, Apr 21, 2020 at 03:13:05PM -0500, Josh Poimboeuf wrote:
> Also, the unreachable annotation at the end of a section is really an
> edge case.  I'm sort of wondering if there's a way to accomplish the
> same thing without storing the last_insn.
> 
> For example, I wonder if we could use find_insn() for some bytes at the
> end of the section.  Most of the time I _think_ there will be a two-byte
> UD2 instruction there anyway.  So maybe we could do something like:
> 
> 	for (offset = rela->sym->sec->len - 1;
> 	     offset > rela->sym->sec->len - 10;
> 	     offset --) {
> 
> 	     insn = find_insn(file, rela->sym->sec, offset);
> 	     if (insn)
> 	     	break;
> 	}
> 
> It's kind of ugly, but then we could maybe avoid the need for the
> last_insn thing.

Sure, that looks fine. I tested this and it looks like the performance
is roughly the same. I'll send v2 shortly.

Sami

  parent reply	other threads:[~2020-04-21 22:03 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-21 18:07 [PATCH 0/3] objtool: add support for >64k sections Sami Tolvanen
2020-04-21 18:07 ` [PATCH 1/3] objtool: use gelf_getsymshndx to handle " Sami Tolvanen
2020-04-21 20:11   ` Kees Cook
2020-04-21 18:07 ` [PATCH 2/3] objtool: optimize insn_hash for split sections Sami Tolvanen
2020-04-21 19:47   ` Peter Zijlstra
2020-04-21 20:13     ` Kees Cook
2020-04-21 20:20     ` Sami Tolvanen
2020-04-21 18:07 ` [PATCH 3/3] objtool: optimize add_dead_ends " Sami Tolvanen
2020-04-21 20:13   ` Josh Poimboeuf
2020-04-21 20:17     ` Kees Cook
2020-04-21 22:02     ` Sami Tolvanen [this message]
2020-04-21 20:14   ` Kees Cook
2020-04-21 20:11 ` [PATCH 0/3] objtool: add support for >64k sections Kees Cook
2020-04-21 22:08 ` [PATCH v2 0/2] " Sami Tolvanen
2020-04-21 22:08   ` [PATCH v2 1/2] objtool: use gelf_getsymshndx to handle " Sami Tolvanen
2020-05-15 17:22     ` [tip: objtool/core] " tip-bot2 for Sami Tolvanen
2020-04-21 22:08   ` [PATCH v2 2/2] objtool: optimize add_dead_ends for split sections Sami Tolvanen
2020-04-21 23:43     ` Kees Cook
2020-05-15 17:22     ` [tip: objtool/core] " tip-bot2 for Sami Tolvanen
2020-04-21 23:52   ` [PATCH v2 0/2] objtool: add support for >64k sections Josh Poimboeuf

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=20200421220258.GA85573@google.com \
    --to=samitolvanen@google.com \
    --cc=jpoimboe@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --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.