From: Julien Thierry <jthierry@redhat.com>
To: Alexandre Chartre <alexandre.chartre@oracle.com>,
Peter Zijlstra <peterz@infradead.org>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
jpoimboe@redhat.com, tglx@linutronix.de
Subject: Re: [PATCH V2 5/9] objtool: Add support for intra-function calls
Date: Wed, 8 Apr 2020 15:19:58 +0100 [thread overview]
Message-ID: <b8d4777e-1c33-7165-33f6-f32007ef7305@redhat.com> (raw)
In-Reply-To: <7ba6d4c9-c1dc-fa83-2ade-b7d3fba9e7fb@oracle.com>
On 4/8/20 3:06 PM, Alexandre Chartre wrote:
>
>
> On 4/7/20 3:28 PM, Alexandre Chartre wrote:
>>
>> On 4/7/20 3:07 PM, Peter Zijlstra wrote:
>>> On Tue, Apr 07, 2020 at 09:31:38AM +0200, Alexandre Chartre wrote:
>>>
>>>> index a62e032863a8..7ee1561bf7ad 100644
>>>> --- a/tools/objtool/arch/x86/decode.c
>>>> +++ b/tools/objtool/arch/x86/decode.c
>>>> @@ -497,3 +497,15 @@ void arch_initial_func_cfi_state(struct
>>>> cfi_state *state)
>>>> state->regs[16].base = CFI_CFA;
>>>> state->regs[16].offset = -8;
>>>> }
>>>> +
>>>> +
>>>> +void arch_configure_intra_function_call(struct stack_op *op)
>>>> +{
>>>> + /*
>>>> + * For the impact on the stack, make an intra-function
>>>> + * call behaves like a push of an immediate value (the
>>>> + * return address).
>>>> + */
>>>> + op->src.type = OP_SRC_CONST;
>>>> + op->dest.type = OP_DEST_PUSH;
>>>> +}
>>>
>>> An alternative is to always set up stack ops for CALL/RET on decode, but
>>> conditionally run update_insn_state() for them.
>>>
>>> Not sure that makes more logical sense, but the patch would be simpler I
>>> think.
>>
>> Right, this would avoid adding a new arch dependent function and the
>> patch
>> will be simpler. This probably makes sense as the stack impact is the
>> same
>> for all calls (but objtool will use it only for intra-function calls).
>>
>
> Actually the processing of the ret instruction is more complicated than I
> anticipated with intra-function calls, and so my implementation is not
> complete at the moment.
>
> The issue is to correctly handle how the ret is going to behave
> depending how
> the stack (or register on arm) is modified before the ret. Adjusting the
> stack
> offset makes the stack state correct, but objtool still needs to correctly
> figure out where the ret is going to return and where the code flow
> continues.
>
A hint indicating the target "jump" address could be useful. It could be
used to add the information on some call/jump dynamic that aren't
associated with jump tables. Currently when objtool finds a jump
dynamic, if no branches were added to it, it will just return.
Having such a hint could help make additional links (at least on arm64).
I don't know what Peter and Josh would think of that (if that helps in
your case of course).
--
Julien Thierry
next prev parent reply other threads:[~2020-04-08 15:22 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-07 7:31 [PATCH V2 0/9] objtool changes to remove all ANNOTATE_NOSPEC_ALTERNATIVE Alexandre Chartre
2020-04-07 7:31 ` [PATCH V2 1/9] objtool: Introduce HINT_RET_OFFSET Alexandre Chartre
2020-04-07 12:53 ` Peter Zijlstra
2020-04-07 13:17 ` Alexandre Chartre
2020-04-07 7:31 ` [PATCH V2 2/9] objtool: UNWIND_HINT_RET_OFFSET should not check registers Alexandre Chartre
2020-05-01 18:22 ` [tip: objtool/core] " tip-bot2 for Alexandre Chartre
2020-04-07 7:31 ` [PATCH V2 3/9] objtool: is_fentry_call() crashes if call has no destination Alexandre Chartre
2020-04-07 7:31 ` [PATCH V2 4/9] objtool: Allow branches within the same alternative Alexandre Chartre
2020-04-07 7:31 ` [PATCH V2 5/9] objtool: Add support for intra-function calls Alexandre Chartre
2020-04-07 13:07 ` Peter Zijlstra
2020-04-07 13:28 ` Alexandre Chartre
2020-04-08 14:06 ` Alexandre Chartre
2020-04-08 14:19 ` Julien Thierry [this message]
2020-04-08 16:03 ` Alexandre Chartre
2020-04-08 16:04 ` Julien Thierry
2020-04-08 17:06 ` Alexandre Chartre
2020-04-08 17:07 ` Julien Thierry
2020-04-07 7:31 ` [PATCH V2 6/9] x86/speculation: Change __FILL_RETURN_BUFFER to work with objtool Alexandre Chartre
2020-04-07 13:27 ` Josh Poimboeuf
2020-04-07 7:31 ` [PATCH V2 7/9] x86/speculation: Annotate intra-function calls Alexandre Chartre
2020-04-07 7:31 ` [PATCH V2 8/9] x86/speculation: Add unwind hint to trampoline return Alexandre Chartre
2020-04-07 7:31 ` [PATCH V2 9/9] x86/speculation: Remove all ANNOTATE_NOSPEC_ALTERNATIVE directives Alexandre Chartre
2020-04-07 13:28 ` Peter Zijlstra
2020-04-07 13:34 ` Josh Poimboeuf
2020-04-07 14:32 ` Alexandre Chartre
2020-04-07 16:18 ` Alexandre Chartre
2020-04-07 16:28 ` Josh Poimboeuf
2020-04-07 17:01 ` Alexandre Chartre
2020-04-07 17:26 ` Peter Zijlstra
2020-04-07 17:27 ` Peter Zijlstra
2020-04-08 21:35 ` Peter Zijlstra
2020-04-09 8:18 ` Alexandre Chartre
2020-04-09 10:34 ` Peter Zijlstra
2020-04-09 10:40 ` Peter Zijlstra
2020-04-07 16:41 ` Peter Zijlstra
2020-04-07 17:04 ` Alexandre Chartre
2020-04-07 13:52 ` Peter Zijlstra
2020-04-07 13:59 ` Peter Zijlstra
2020-04-07 13:35 ` [PATCH V2 0/9] objtool changes to remove all ANNOTATE_NOSPEC_ALTERNATIVE Josh Poimboeuf
2020-04-07 14:02 ` 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=b8d4777e-1c33-7165-33f6-f32007ef7305@redhat.com \
--to=jthierry@redhat.com \
--cc=alexandre.chartre@oracle.com \
--cc=jpoimboe@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®