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 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.

    alex.

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