Rewrite Obj-C workflow in Rust

This is functionally equivalent to the previous workflow_objc, with the
following changes:
1. It mutates the `core.function.metaAnalysis` workflow rather than
   registering a new named workflow. The activities now all check for
   the presence of the Objective-C metadata added by `ObjCProcessor` to
   determine whether they should do work, rather than relying on
   `MachoView` to override the function workflow when Objective-C
   metadata is present. This fixes
   https://github.com/Vector35/binaryninja-api/issues/6779.
2. The auto-inlining of `objc_msgSend` selector stub functions is
   performed in a separate activity from the processing of
   `objc_msgSend` call sites. The selector stub inlining activity is
   configured so that it does not run in `DSCView` as the shared cache
   needs different behavior for stub functions more generally that
   `SharedCacheWorkflow` already provides.
3. The way that types like `id` and `SEL` are referenced is fixed so
   that they show up as `id` rather than `objc_struct*`.

This also replaces the Objective-C portion of the shared cache's
workflow, and incorporates several bug fixes that had been applied to it
but not the standalone Objective-C workflow.

1 files changed, 0 insertions, 63 deletions

diff --git a/plugins/workflow_objc/MessageHandler.cpp b/plugins/workflow_objc/MessageHandler.cpp
deleted file mode 100644
index 5c3422b2..00000000
--- a/plugins/workflow_objc/MessageHandler.cpp
+++ /dev/null
@@ -1,63 +0,0 @@
-#include "MessageHandler.h"
-
-using namespace BinaryNinja;
-
-MessageHandler::MessageHandler(Ref<BinaryView> data)
-{
-    m_msgSendFunctions = findMsgSendFunctions(data);
-}
-
-std::set<uint64_t> MessageHandler::findMsgSendFunctions(BinaryNinja::Ref<BinaryNinja::BinaryView> data)
-{
-    std::set<uint64_t> results;
-
-    const auto authStubsSection = data->GetSectionByName("__auth_stubs");
-    const auto stubsSection = data->GetSectionByName("__stubs");
-    const auto authGotSection = data->GetSectionByName("__auth_got");
-    const auto gotSection = data->GetSectionByName("__got");
-    const auto laSymbolPtrSection = data->GetSectionByName("__la_symbol_ptr");
-
-    // Shorthand to check if a symbol lies in a given section.
-    auto sectionContains = [](Ref<Section> section, Ref<Symbol> symbol) {
-        const auto start = section->GetStart();
-        const auto length = section->GetLength();
-        const auto address = symbol->GetAddress();
-
-        return (uint64_t)(address - start) <= length;
-    };
-
-    // There can be multiple `_objc_msgSend` symbols in the same binary; there
-    // may even be lots. Some of them are valid, others aren't. In order of
-    // preference, `_objc_msgSend` symbols in the following sections are
-    // preferred:
-    //
-    //   1. __auth_stubs
-    //   2. __stubs
-    //   3. __auth_got
-    //   4. __got
-    //   ?. __la_symbol_ptr
-    //
-    // There is often an `_objc_msgSend` symbol that is a stub function, found
-    // in the `__stubs` section, which will come with an imported symbol of the
-    // same name in the `__got` section. Not all `__objc_msgSend` calls will be
-    // routed through the stub function, making it important to make note of
-    // both symbols' addresses. Furthermore, on ARM64, the `__auth{stubs,got}`
-    // sections are preferred over their unauthenticated counterparts.
-    const auto candidates = data->GetSymbolsByName("_objc_msgSend");
-    for (const auto& c : candidates) {
-        if ((authStubsSection && sectionContains(authStubsSection, c))
-            || (stubsSection && sectionContains(stubsSection, c))
-            || (authGotSection && sectionContains(authGotSection, c))
-            || (gotSection && sectionContains(gotSection, c))
-            || (laSymbolPtrSection && sectionContains(laSymbolPtrSection, c))) {
-            results.insert(c->GetAddress());
-        }
-    }
-
-    return results;
-}
-
-bool MessageHandler::isMessageSend(uint64_t functionAddress)
-{
-    return m_msgSendFunctions.count(functionAddress);
-}