From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Alexandre Chartre <alexandre.chartre@oracle.com>,
Julien Thierry <jthierry@redhat.com>,
x86@kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de
Subject: Re: [PATCH 3/7] objtool: Add support for intra-function calls
Date: Thu, 2 Apr 2020 10:54:36 -0500 [thread overview]
Message-ID: <20200402155436.q6qbuezmmarr24qp@treble> (raw)
In-Reply-To: <20200402150407.GD20730@hirez.programming.kicks-ass.net>
On Thu, Apr 02, 2020 at 05:04:07PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 02, 2020 at 03:24:45PM +0200, Alexandre Chartre wrote:
> > On 4/2/20 2:53 PM, Julien Thierry wrote:
> > > On 4/2/20 9:22 AM, Alexandre Chartre wrote:
>
> > > > +Â Â Â sec = find_section_by_name(file->elf,
> > > > +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ".rela.discard.intra_function_call");
> > >
> > > I'm wondering, do we really need to annotate the intra_function_call
> > > and group the in a section?
> > >
> > > Would it be a problem to consider all (static) call instructions with
> > > a destination that is not the start offset of a symbol to be an
> > > intra-function call (and set insn->intra_function_call and
> > > insn->jump_dest accordingly)?
> >
> > Correct, we could automatically detect intra-function calls instead of
> > having to annotate them. However, I choose to annotate them because I don't
> > think that's not an expected construct in a "normal" code flow (at least
> > on x86). So objtool would still issue a warning on intra-function calls
> > by default, and you can annotate them to indicate if they are expected.
>
> I wondered the same thing when reading the patch. I'm confliected on
> this. On the one hand auto-detecting this seems like an excellent idea.
>
> If/when the compiler generates them, they had better be okay too.
>
> Josh?
In general I prefer to keep it simple, and keep the annotations to a
minimum. And I don't think this warning has ever found anything useful.
So I'd be inclined to say just allow them and automatically detect them.
However the fact that arm64 asm actually uses them worries me a bit.
So for me it kind of hinges on whether arm64 has a legitimate use case
for them, or if the warning actually points to smelly code.
--
Josh
next prev parent reply other threads:[~2020-04-02 15:54 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-02 8:22 [PATCH 0/7] objtool changes to remove most ANNOTATE_NOSPEC_ALTERNATIVE Alexandre Chartre
2020-04-02 8:22 ` [PATCH 1/7] objtool: is_fentry_call() crashes if call has no destination Alexandre Chartre
2020-04-02 8:22 ` [PATCH 2/7] objtool: Allow branches within the same alternative Alexandre Chartre
2020-04-02 12:03 ` Julien Thierry
2020-04-02 12:38 ` Alexandre Chartre
2020-04-02 8:22 ` [PATCH 3/7] objtool: Add support for intra-function calls Alexandre Chartre
2020-04-02 12:53 ` Julien Thierry
2020-04-02 13:24 ` Alexandre Chartre
2020-04-02 13:38 ` Julien Thierry
2020-04-02 14:56 ` Alexandre Chartre
2020-04-02 15:04 ` Peter Zijlstra
2020-04-02 15:54 ` Josh Poimboeuf [this message]
2020-04-03 7:06 ` Alexandre Chartre
2020-04-02 15:49 ` Josh Poimboeuf
2020-04-02 17:27 ` Josh Poimboeuf
2020-04-03 8:01 ` Julien Thierry
2020-04-03 12:41 ` Peter Zijlstra
2020-04-03 12:49 ` Julien Thierry
2020-04-03 14:37 ` Peter Zijlstra
2020-04-03 14:44 ` Josh Poimboeuf
2020-04-02 8:22 ` [PATCH 4/7] objtool: Add support for return trampoline call Alexandre Chartre
2020-04-02 13:26 ` Julien Thierry
2020-04-02 14:46 ` Alexandre Chartre
2020-04-02 15:31 ` Julien Thierry
2020-04-02 15:40 ` Peter Zijlstra
2020-04-03 8:11 ` Julien Thierry
2020-04-03 15:17 ` Josh Poimboeuf
2020-04-03 15:22 ` Josh Poimboeuf
2020-04-03 15:32 ` Josh Poimboeuf
2020-04-03 15:46 ` Peter Zijlstra
2020-04-03 15:55 ` Josh Poimboeuf
2020-04-04 13:32 ` Peter Zijlstra
2020-04-04 14:22 ` Josh Poimboeuf
2020-04-04 15:51 ` Peter Zijlstra
2020-04-06 8:19 ` Alexandre Chartre
2020-04-06 9:31 ` Peter Zijlstra
2020-04-06 11:03 ` Alexandre Chartre
2020-04-06 14:16 ` Josh Poimboeuf
2020-04-02 15:27 ` Peter Zijlstra
2020-04-03 7:19 ` Alexandre Chartre
2020-04-06 14:34 ` Alexandre Chartre
2020-04-06 14:55 ` Alexandre Chartre
2020-04-02 8:22 ` [PATCH 5/7] x86/speculation: Annotate intra-function calls Alexandre Chartre
2020-04-03 16:05 ` Josh Poimboeuf
2020-04-03 16:16 ` Josh Poimboeuf
2020-04-03 17:14 ` Alexandre Chartre
2020-04-03 17:18 ` Peter Zijlstra
2020-04-03 17:24 ` Josh Poimboeuf
2020-04-03 18:20 ` Peter Zijlstra
2020-04-02 8:22 ` [PATCH 6/7] x86/speculation: Annotate retpoline return instructions Alexandre Chartre
2020-04-02 8:22 ` [PATCH 7/7] x86/speculation: Remove most ANNOTATE_NOSPEC_ALTERNATIVE Alexandre Chartre
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=20200402155436.q6qbuezmmarr24qp@treble \
--to=jpoimboe@redhat.com \
--cc=alexandre.chartre@oracle.com \
--cc=jthierry@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--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
all inboxes | Powered by JetHome®