Messages in this thread | | | Subject | Re: [PATCH V2 5/9] objtool: Add support for intra-function calls | From | Julien Thierry <> | Date | Wed, 8 Apr 2020 18:07:00 +0100 |
| |
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
| |