From: Peter Zijlstra <peterz@infradead.org>
To: Miroslav Benes <mbenes@suse.cz>
Cc: jpoimboe@redhat.com, alexandre.chartre@oracle.com,
linux-kernel@vger.kernel.org, jthierry@redhat.com,
tglx@linutronix.de, x86@kernel.org
Subject: Re: [PATCH 4/8] objtool: Add support for intra-function calls
Date: Thu, 23 Apr 2020 17:22:43 +0200 [thread overview]
Message-ID: <20200423152243.GV20730@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <alpine.LSU.2.21.2004231619070.6520@pobox.suse.cz>
On Thu, Apr 23, 2020 at 04:34:21PM +0200, Miroslav Benes wrote:
> > /*
> > * Find the destination instructions for all calls.
> > */
> > @@ -715,10 +725,7 @@ static int add_call_destinations(struct
> > continue;
> >
> > if (!insn->call_dest) {
> > - WARN_FUNC("unsupported intra-function call",
> > - insn->sec, insn->offset);
> > - if (retpoline)
> > - WARN("If this is a retpoline, please patch it in with alternatives and annotate it with ANNOTATE_NOSPEC_ALTERNATIVE.");
> > + WARN_FUNC("intra-function call", insn->sec, insn->offset);
>
> "unsupported intra-function call"?
Well, I think the thinking was that intra-function calls are actually
supported, 'unannotated' perhaps ?
> > return -1;
> > }
> >
> > @@ -741,6 +748,12 @@ static int add_call_destinations(struct
> > }
> > } else
> > insn->call_dest = rela->sym;
> > +
> > + /*
> > + * Whatever stack impact regular CALLs have, should be
> > + * undone by the RETURN of the called function.
>
> * Annotated intra-function CALLs are treated as JMPs with a stack_op.
> * See read_intra_function_calls().
>
> would make it a bit clearer.
That doesn't work for me; we want to explain why it is OK to delete
stack_ops for regular CALLs. The reason this is OK, is because they're
matched by RETURN.
> > + */
> > + remove_insn_ops(insn);
> > }
> >
> > return 0;
> > @@ -1416,6 +1429,57 @@ static int read_instr_hints(struct objto
> > return 0;
> > }
> >
> > +static int read_intra_function_calls(struct objtool_file *file)
> > +{
> > + struct instruction *insn;
> > + struct section *sec;
> > + struct rela *rela;
> > +
> > + sec = find_section_by_name(file->elf, ".rela.discard.intra_function_calls");
> > + if (!sec)
> > + return 0;
> > +
> > + list_for_each_entry(rela, &sec->rela_list, list) {
> > + unsigned long dest_off;
> > +
> > + if (rela->sym->type != STT_SECTION) {
> > + WARN("unexpected relocation symbol type in %s",
> > + sec->name);
> > + return -1;
> > + }
> > +
> > + insn = find_insn(file, rela->sym->sec, rela->addend);
> > + if (!insn) {
> > + WARN("bad .discard.intra_function_call entry");
> > + return -1;
> > + }
> > +
> > + if (insn->type != INSN_CALL) {
> > + WARN_FUNC("intra_function_call not a direct call",
> > + insn->sec, insn->offset);
> > + return -1;
> > + }
> > +
> > + /*
> > + * Treat intra-function CALLs as JMPs, but with a stack_op.
> > + * Also see how setup_call_dest() strips stack_ops from normal
> > + * CALLs.
>
> /*
> * Treat annotated intra-function CALLs as JMPs, but with a stack_op.
> * Also see how add_call_destinations() strips stack_ops from normal
> * CALLs.
> */
>
> ? (note added "annotated" and s/setup_call_dest/add_call_destinations/)
Unannotated intra-function calls are not allowed, so I don't see a
reason to make that distinction, but sure.
> > + */
> > + insn->type = INSN_JUMP_UNCONDITIONAL;
>
> [...]
>
> > @@ -2245,6 +2313,9 @@ static int validate_branch(struct objtoo
> > return 0;
> > }
> >
> > + if (handle_insn_ops(insn, &state))
> > + return 1;
> > +
> > switch (insn->type) {
> >
> > case INSN_RETURN:
> > @@ -2304,9 +2375,6 @@ static int validate_branch(struct objtoo
> > break;
> >
> > case INSN_EXCEPTION_RETURN:
> > - if (handle_insn_ops(insn, &state))
> > - return 1;
> > -
> > /*
> > * This handles x86's sync_core() case, where we use an
> > * IRET to self. All 'normal' IRET instructions are in
> > @@ -2326,8 +2394,6 @@ static int validate_branch(struct objtoo
> > return 0;
> >
> > case INSN_STACK:
> > - if (handle_insn_ops(insn, &state))
> > - return 1;
> > break;
>
> So we could get rid of INSN_STACK now as Julien proposed, couldn't we? If
> I am not missing something. handle_insn_ops() is called unconditionally
> here for all insn types and you remove stack_ops when unneeded.
Yes, INSN_STACK can now go away in favour of NOPs with stack_ops.
Separate patch though.
> We could also go ahead with Julien's proposal to remove
> INSN_EXCEPTION_RETURN hack and move it to tools/objtool/arch/x86/decode.c.
I don't immediately see how; we don't have a symbol there.
next prev parent reply other threads:[~2020-04-23 15:22 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-23 12:47 [PATCH 0/8] objtool vs retpoline Peter Zijlstra
2020-04-23 12:47 ` [PATCH 1/8] objtool: is_fentry_call() crashes if call has no destination Peter Zijlstra
2020-04-23 12:47 ` [PATCH 2/8] objtool: UNWIND_HINT_RET_OFFSET should not check registers Peter Zijlstra
2020-04-23 12:47 ` [PATCH 3/8] objtool: Rework allocating stack_ops on decode Peter Zijlstra
2020-04-23 15:40 ` Alexandre Chartre
2020-04-23 15:54 ` Peter Zijlstra
2020-04-24 7:06 ` Alexandre Chartre
2020-04-23 16:16 ` Peter Zijlstra
2020-04-24 9:43 ` Miroslav Benes
2020-04-23 12:47 ` [PATCH 4/8] objtool: Add support for intra-function calls Peter Zijlstra
2020-04-23 14:34 ` Miroslav Benes
2020-04-23 15:22 ` Peter Zijlstra [this message]
2020-04-24 9:37 ` Miroslav Benes
2020-04-24 14:07 ` Miroslav Benes
2020-04-23 12:47 ` [PATCH 5/8] x86/speculation: Change FILL_RETURN_BUFFER to work with objtool Peter Zijlstra
2020-04-23 15:45 ` Alexandre Chartre
2020-04-24 19:04 ` Josh Poimboeuf
2020-04-23 12:47 ` [PATCH 6/8] x86: Simplify retpoline declaration Peter Zijlstra
2020-04-24 19:09 ` Josh Poimboeuf
2020-04-23 12:47 ` [PATCH 7/8] x86: Change {JMP,CALL}_NOSPEC argument Peter Zijlstra
2020-04-23 12:47 ` [PATCH 8/8] x86/retpoline: Fix retpoline unwind Peter Zijlstra
2020-04-23 12:59 ` Peter Zijlstra
2020-04-24 19:30 ` Josh Poimboeuf
2020-04-28 18:30 ` Peter Zijlstra
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=20200423152243.GV20730@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=alexandre.chartre@oracle.com \
--cc=jpoimboe@redhat.com \
--cc=jthierry@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbenes@suse.cz \
--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