| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
applied
Snapshot data is applied when loading from a database, rebasing the
view, etc.
|
|
|
|
The iterators now store an offset into the operand storage, rather than
a pointer. Deferencing the iterator retrieves the value at that offset
from the IL function.
This issue existed prior to the operand list storage refactor, but
became easier to hit after that change. The separate operand list vector
is smaller and thus more likely to reallocate when a new instruction is
appended.
|
|
|
|
Rather than using chains of `UNDEF` instructions, the contents of these
lists are in a vector alongside the instructions. The instruction itself
stores the entry count and offset into this second vector at which the
associated items can be found.
This improves analysis performance by around 2% and decreases memory
usage by around 5%.
|
|
the UI.
|
|
|
|
Register plugins which are available outside the context of a binary view
|
|
Previously you must have written the type library to disk
|
|
Useful when relocating information between type libraries before finalization
|
|
to be considered for heuristic calling convention detection
|
|
Adds a GetInstructionTextWithContext callback to the architecture class
that can be used to pass data from AnalyzeBasicBlocks. This same context
is also supplied to LiftFunction and allows for supplying shared function
and/or binary view level information across basic block analysis, function
lifting, and disassembly text rendering
|
|
container file entries.
|
|
|
|
documentation.
|
|
This change allows architecture plugins to override the LiftFunction
callback to iterate a function's basic block list and lift entire
functions at once. This is required for architectures such as TMS320
C6x, which have non-traditional "delay slots" in that branches, loads,
and other instructions take multiple cycles to complete, and branch
instructions can reside within the delay slots of other branches.
|
|
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.
|
|
|
|
|
|
Made possible by the new attributes in binja's type system.
|
|
This allows a few widely-used enums to be shrunk from 4 bytes to 1 byte,
improving packing when they're used as struct members.
To remain compatible with C, we follow CoreFoundation's approach and use
a macro when defining the enum:
```
#if defined(__cplusplus) || __has_extension(c_fixed_enum)
#define BN_ENUM(type, name) enum name : type
#else
#define BN_ENUM(type, name) typedef type name; enum
#endif
BN_ENUM(uint8_t, SomeEnum)
{
...
}
```
In C++ and C23 this will expand to an enum with a fixed underlying type.
In older C language versions, this will result in the enum type being a
typedef of the underlying type, with an unnamed enum providing the enum
values.
Minor changes were needed within the Python bindings to update places
that made assumptions about the underlying type of the enums.
|
|
|
|
|
|
|
|
|
|
consistent, lock-free AnalysisContext queries.
|
|
|
|
|
|
Loggers are not owned by a specific thread and many are used by multiple threads. The indenting APIs could not be made to be thread safe in any way as they exist, so they have been removed. The data races caused by the indenting APIs are actually an important stability issue that could cause the indentation level to go out of bounds and crash the product.
If you were using the indentation APIs, you will need to rewrite the usage to manually manage the indentation level in a thread safe way.
|
|
This reverts commit 72fcf44f3731ade3cf1310da55f633f1cb9069ce.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also adds support for parsing bitfields in PDB, DWARF and SVD plugins
WIP: API needs to be considered more, also need to find type related apis that may need to be rethought.
|
|
|
|
|
|
|
|
|
|
|
|
Add note about type_names not being sorted anymore
|
|
|
|
|
|
|
|
|
