diff options
| author | Mark Rowe <mark@vector35.com> | 2025-11-18 15:45:15 -0800 |
|---|---|---|
| committer | Mark Rowe <mark@vector35.com> | 2026-01-14 09:34:32 -0800 |
| commit | 6e50ceda4e65e5952e59449fad4953ea6c5aaf37 (patch) | |
| tree | 3f9defd37d0b2d1b7725b0f876fa474b6301d056 /binaryninjacore.h | |
| parent | 56010d289afa142ebd206db8fc3b22f89d7a4ec0 (diff) | |
Allow controlling which address is used for instructions created when inlining during analysis
Previously the address of the instruction in the function being inlined
was used as the new instruction's address when copying it during
inlining. Now there is an additional option: use the address of the
call instruction that is being replaced as the new instruction's
address.
This new mode is useful when inlining thunks or stub functions, but care
must be taken if using it beyond that.
The benefit is that it ensures that when a function contains multiple
calls to the same stub function, each inlined copy ends up with distinct
addresses. This ensures that call type adjustments and other overrides
that are stored on the function and keyed by address can be applied
independently to each callsite that was inlined.
The trade-off is that if the function being inlined contains non-trivial
logic, all of the inlined instructions sharing an address will limit
what type of adjustments can be applied to them.
The Objective-C and shared cache workflows are updated to take advantage
of this new mode when they enable inlining of stub functions. This will
make it possible for multiple calls to the same runtime function within
a single function to have separate call type adjustments applied in the
future.
Diffstat (limited to 'binaryninjacore.h')
| -rw-r--r-- | binaryninjacore.h | 32 |
1 files changed, 30 insertions, 2 deletions
diff --git a/binaryninjacore.h b/binaryninjacore.h index 8144ed7e..1e346bb1 100644 --- a/binaryninjacore.h +++ b/binaryninjacore.h @@ -1131,6 +1131,33 @@ extern "C" MemoryIntrinsicClass }; + BN_ENUM(uint8_t, BNInlineDuringAnalysis) + { + // The called function should not be inlined. + DoNotInlineCall, + + // The called function should be inlined, with the inlined + // instructions preserving their original addresses. + // This was the only behavior available up through Binary Ninja 5.2. + InlinePreservingTargetInstructionAddresses, + + // The called function should be inlined, with the inlined + // instructions using the call site address as their address. + // This ensures that when the function is inlined into a caller + // multiple times, each occurrence can have different adjustments + // applied to it. The trade-off is that the instructions inlined + // at a given call site have the same address, which in turn + // prevents applying adjustments that depend on instruction + // address to only a subset of those instructions. + InlineUsingCallAddress, + }; + + typedef struct BNInlineDuringAnalysisWithConfidence + { + BNInlineDuringAnalysis value; + uint8_t confidence; + } BNInlineDuringAnalysisWithConfidence; + typedef struct BNLowLevelILInstruction { BNLowLevelILOperation operation; @@ -5175,8 +5202,9 @@ extern "C" BINARYNINJACOREAPI BNRegisterValueWithConfidence BNGetFunctionRegisterValueAtExit(BNFunction* func, uint32_t reg); BINARYNINJACOREAPI BNBoolWithConfidence BNIsFunctionInlinedDuringAnalysis(BNFunction* func); - BINARYNINJACOREAPI void BNSetAutoFunctionInlinedDuringAnalysis(BNFunction* func, BNBoolWithConfidence inlined); - BINARYNINJACOREAPI void BNSetUserFunctionInlinedDuringAnalysis(BNFunction* func, BNBoolWithConfidence inlined); + BINARYNINJACOREAPI BNInlineDuringAnalysisWithConfidence BNGetFunctionInlinedDuringAnalysis(BNFunction* func); + BINARYNINJACOREAPI void BNSetAutoFunctionInlinedDuringAnalysis(BNFunction* func, BNInlineDuringAnalysisWithConfidence inlined); + BINARYNINJACOREAPI void BNSetUserFunctionInlinedDuringAnalysis(BNFunction* func, BNInlineDuringAnalysisWithConfidence inlined); BINARYNINJACOREAPI bool BNGetInstructionContainingAddress( BNFunction* func, BNArchitecture* arch, uint64_t addr, uint64_t* start); |
