| Age | Commit message (Collapse) | Author |
|---|
|
- Make `SharedCache::m_entries` a simple std::vector we never lookup based off the entry ID
- Remove some old comments
- Rename some old variables so that they are accurate
- Fix compiler warnings
- Remove some unneeded copying
|
|
This improves symbol recovery drastically on newer shared caches
Related PR: https://github.com/Vector35/binaryninja-api/pull/6210
|
|
And also removed unneeded VMReader construction in ApplyRegion
|
|
This made the macho objective-c processor aware of images and was passed around everywhere, instead we have an overridable section getter that gives the control over the section retrieval to the derived processor.
In the case of shared cache this means we can store the image to be processed and then use the header to locate the relevant sections.
Fixes: https://github.com/Vector35/binaryninja-api/issues/6594
|
|
adding new images and regions
Within the user section creation we will assume that because a non-default section was added, we should mark all functions for reanalysis. From initial testing
this isn't an extreme slowdown, but with the addition of more images the number of queued up functions becomes much greater, even if those are unmarked immediately
and processing of those functions isn't slow it is unneeded and might lead to other non-obvious slowdowns.
To be clear, we do not need to queue up functions from already analyzed images to be analyzed again, there is no benefit, our workflow handles cross images calls already,
so those places will already be queued up, and if they aren't, that is the issue to solve, not this.
|
|
Fixes https://github.com/Vector35/binaryninja-api/issues/6561
- Also tightens the SharedCache class to move only, to prevent accidental copies.
- Also removes some extra copies in FFI when should pass by ref
- Also adds `get_symbol_with_name` to python API
The current named symbol map is populated in a worker thread spawned in the view init. This is because populating the map can take about 1 second.
If we are fine with another 1 second added to the view init time then we can add it serially but I don't think this way is _that_ bad, no analysis consults
this, however a user might add a workflow that would be racing this. So we need to add a mutex.
|
|
|
|
Apparently the view metadata is not available until after view init
|
|
|
|
|
|
In absence of a better name, this commit refactors the shared cache code.
|
