Re: [PATCH V2 5/9] objtool: Add support for intra-function calls

[Julien Thierry <jthierry@redhat.com>]

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.

This way the hint could also be used for other instructions (e.g. 
INSN_JUMP_DYNAMIC).



-- 
Julien Thierry