From: Alexandre Chartre <alexandre.chartre@oracle.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
jpoimboe@redhat.com, jthierry@redhat.com, tglx@linutronix.de
Subject: Re: [PATCH V2 5/9] objtool: Add support for intra-function calls
Date: Wed, 8 Apr 2020 16:06:18 +0200 [thread overview]
Message-ID: <7ba6d4c9-c1dc-fa83-2ade-b7d3fba9e7fb@oracle.com> (raw)
In-Reply-To: <40b19a8e-ae5e-623e-fb3f-261f9fec2ea5@oracle.com>
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.
alex.
next prev parent reply other threads:[~2020-04-08 14:04 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 [this message]
2020-04-08 14:19 ` Julien Thierry
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=7ba6d4c9-c1dc-fa83-2ade-b7d3fba9e7fb@oracle.com \
--to=alexandre.chartre@oracle.com \
--cc=jpoimboe@redhat.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®