lkml.org 
[lkml]   [2020]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH V2 5/9] objtool: Add support for intra-function calls
From
Date


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

\
 
 \ /
  Last update: 2020-04-08 17:22    [W:0.125 / U:0.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site