| Age | Commit message (Collapse) | Author |
|
pluginManager.debug
|
|
This reverts commit 5bafe5c7bdb0b56037a0b5c573236f9c6367353a.
|
|
|
|
|
|
analysis.objectiveC.resolveDynamicDispatch is enabled
|
|
Rather than introducing duplicate definitions of these types, use a
NamedTypeReference that will be resolved to the type from the libobjc
type library when it is loaded.
This prevents these types from showing up as id_1 / SEL_1 in some places
rather than as their expected names.
|
|
|
|
objc_msgSend stub
|
|
The `__objc_ivar` section contains [values of type `long` for all
architectures except arm64, where it contains `int`][1].
This fixes problems with resolving non-fragile ivar accesses to struct
field accesses on arm64 and 32-bit architectures.
[1]: https://github.com/llvm/llvm-project/blob/535d6917ec3308ade866f205644b740666312342/clang/lib/CodeGen/CGObjCMac.cpp#L5628-L5629
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
`UpdateInfoFetcher` performs fetches asynchronously and needs to ensure
it remains alive for the duration of the fetch. The fetch may not
complete before its creator is destroyed, so `UpdateInfoFetcher` needs
to control its own lifetime via `std::enable_shared_from_this`.
|
|
|
|
Avoid copying the vector of symbols where possible. When no filter
string is applied we no longer copy the entire vector symbols by having
the symbols used for display be indirected via a pointer. It points
either to the unfiltered symbols or the filtered symbols.
Some unncessary copies have been removed by using `std::move` where
appropriate.
Filtering has been updated to avoid `std::vector::reserve` /
`std::vector::shrink_to_fit` in favor of letting the filtered vector
control its own growth and reuse its buffer. This avoids allocating a
~100MB buffer every time we update the filter only to later reallocate
and move the contents into a smaller buffer. Instead the buffer grows
via `std::vector`'s usual growth algorithm and it is preserved across
filter calls to avoid unnecessarily reallocating it, and only shrink the
buffer if it has shrunk significantly vs previous iterations.
|
|
We're copying `std::string` objects that know their length. There's no
reason to force a call to `strlen`.
|
|
`GetRegionAt` was really providing the semantics of
`GetRegionContaining` due to `m_regions` being an `AddressRangeMap` and
using transparent comparators to allow `find` to work with any address
in the range.
`GetRegionAt` is updated to verify that the start address of the region
that was found matches the requested address. `GetRegionContaining` is
updated to use `AddressRangeMap::find` rather than doing a linear search
over all regions.
|
|
The `ExportsTreeView` now asks the model to pause / resume updates when
its visibility changes. When paused, all notifications from the view are
ignored. When resumed, notifications set a flag to indicate that an
update is needed and resume the update timer if it is not already
active. The timer is stopped after an update is processed.
There's some extra complexity here to avoid emitting a signal for every
`BinaryView` notification that is processed. These notifications are
typically generated on background threads. The overhead of emitting a
signal and it being routed to the main thread adds up given the number
of notifications involved when loading a large binary.
|
|
|
|
|
|
on references
|
|
|
|
|
|
|
|
|
|
`__objc_stubs` is not technically Objective-C metadata, but binaries
containing Objective-C stubs need the same processing.
`MachoView` was previously only enabling the Objective-C workflow if it
thinks there is type metadata. The same criteria was used to determine
whether to process Objective-C metadata via `MachoObjCProcessor`.
This meant binaries with `__objc_stubs` but no Objective-C type metadata
were not running the Objective-C workflow, preventing stub functions
from being inlined during analysis.
|
|
This would leak if parsing of CFStrings was enabled while parsing of
Objective-C metadata was disabled.
It would also leak if exceptions were thrown or early returns were taken
in the ~500 lines between where the object was allocated and it was
deleted.
|
|
`SymbolQueue`'s lifetime was being managed via `new` / `delete`. This
was error-prone in the face of code that can a) throw exceptions, or b)
return early. Typically the solution would be to move to
`std::unique_ptr` and call it a day, but nothing is ever easy.
The `SymbolQueue`s created by `ObjCProcessor` are intended to live for
the duration of `ProcessObjCData` and `ProcessCFStrings` methods. Since
they are used multiple levels down the call tree, the active
`SymbolQueue` is stored as a member variable on `ObjCProcessor`.
Switching to `std::unique_ptr` would ensure that the `SymbolQueue` is
destroyed, but would leave a dangling pointer in the member variable.
To address this I'm introducing a `ScopedSingleton` class that provides
a thread-local singleton whose lifetime is controlled by a guard object.
`ProcessObjCData` / `ProcessCFStrings` call `ScopedSymbolQueue::Make`
and store the returned guard object in a local. Code that accesses the
symbol queue uses `ScopedSymbolQueue::Get` to retrieve the current
instance. The guard object ensures the `SymbolQueue` is deleted and the
`current` pointer is cleared no matter how the scope is exited.
A better longer-term design is to introduce a class for processing the
Objective-C runtime metadata and a class for processing constants such
as `CFString`s. These could directly own the symbol queue so it would be
accessible to any member functions that define symbols. This is a more
involved refactoring than I have time for right now.
|
|
|
|
When clicking outside the command palette, focus is now properly
transferred to the clicked widget instead of being restored to
the previously focused widget. Escape key still restores focus
as expected.
|
|
This adds support for the `__objc_arrayobj`, `_objc_dictobj`,
`__objc_intobj`, `__objc_floatobj`, `__objc_doubleobj` and
`__objc_dateobj` sections that contain Objective-C constants. These are
emitted by Apple's versions of Clang for `const` literals, amongst other
things.
|
|
|
|
|
|
|
|
|
|
The order that the operands to `+` are evaluated in is unspecified. Clang
happens to evaluate them left to right and gives the expected answer.
MSVC picks the opposite order and so the value it computes is off by 4.
This was resulting in missing method names when arm64 binaries
containing Objective-C are analyzed on Windows.
|
|
|
|
|
|
|
|
Need this for WARP, see next commit
|
|
To allow for creating reports outside the context of a view
|
|
|
|
|
|
Discovered when poking at variable values in WARP
|