Re: [PATCH V2 5/9] objtool: Add support for intra-function calls
From: Julien Thierry
Date: Wed Apr 08 2020 - 13:07:10 EST
On 4/8/20 6:06 PM, Alexandre Chartre wrote:
On 4/8/20 6:04 PM, Julien Thierry wrote:
On 4/8/20 5:03 PM, Alexandre Chartre wrote:
On 4/8/20 4:19 PM, Julien Thierry wrote:
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).
Yes, I am thinking about tracking intra-function call return address,
and having hints to specify a return address changes. For example,
on x86, when we push the branch address on the stack we overwrite the
last return address (the return address of the last intra-function
call).
Then the return instruction can figure out where to branch.
I see, I was thinking about a more generic hint, that would just
indicate "this instruction actually jumps here". So in your case it
would just point that a certain return instruction causes to branch
somewhere.
I thought about doing that but the problem is that on x86 the same
retpoline code can branch differently depending on how it is used.
Basically we have a return instruction that will branch differently
based on what's on the stack. So we can just tell that this ret
instruction will branch/return there.
Oh, I see. Nevermind then!
--
Julien Thierry