Плюсы

Приветствую,

Сначала о проблеме/задаче:
Начав писать очередной плагин-отладчик для ретро-платформы под IDA Pro (по секрету: это будет SNES), я столкнулся со следующим набором, который требовалось подружить:

1. Ядро эмулятора написано на C++ и компилируется в DLL
2. GUI эмулятора написано на C# и использует DLL-ку ядра для управления эмуляцией
3. IDA Pro, которая использует плагины либо на питоне, либо на C++ в виде DLL (а отладчики только на C++)

Мне нужно было как-то обращаться из IDA к ядру эмуляции (пошаговая отладка, регистры, память и т.п.) так, чтобы и IDA и графический интерфейс имели одно общее состояние ядра.

Вариантов решения проблемы на старте виделось несколько (не все из них правильные), но о каждом по порядку:

1) Сделать LoadLibrary("emu_core.dll"), затем GetProcAddress(core, "Pause") и pause(), чтобы, например, сделать в эмуляторе паузу.

Я тогда думал: вот оно идеальное решение с наименьшим количеством изменений в код (и от ядра, и от GUI исходники у меня имеются)! Но, проблемой здесь стало то, что состояние ядра, опять же, хранится в DLL-ке, которая, в свою очередь, загружена в процесс UI, и только там и происходят изменения.

В итоге, загрузив DLL-ку в плагине для IDA, я получил непроинициализированное состояние ядра. Нужно было придумывать другое решение.

2) Сделать что-то типа хост-процесса, который бы и работал с единственным экземпляром ядра, а все остальные Ида и GUI, обращались бы к этому процессу через RPC-протокол.

Идея вполне здравая, только имелось несколько препятствий в её использовании:

• IDA должна реагировать на события эмуляции (брейкоинты, пауза, reset), т.е. хостовое приложение должно быть активным, а отладчик должен всё время ожидать сообщения от ядра, через хост, себе.
• Колбэки. На самом деле, это уже заложенный в ядре эмулятора функционал, позволяющий решить первый пункт, но, как решать его через RPC я не знал.

Решение

Тогда мне посоветовали взглянуть в сторону COM. Ведь у него, действительно, уже имеется своя замечательная реализация RPC с колбэками и интерфейсами. Которую, к тому же, можно использовать через WinAPI (т.е. C/C++) и нативно в C#.

А т.к. GUI эмулятора был на шарпе, дело было за малым. Оставалось только воспользоваться его возможностями по работе с COM-интерфейсами.

Схема получается следующей:

1) Классы и типы данных, которые могут быть использованы через COM, помечаем как [ComVisible(true)]. К счастью, если вдруг какой-то тип вы всё же забудете пометить как видимый, используемые далее инструменты вам об этом скажут (иногда явно, иногда нет, но скажут)

2) Создаю интерфейс, в котором будут описаны все методы, необходимые внешнему пользователю (отладчику в IDA). Помечаю его ещё двумя тегами (к уже имеющемуся ComVisible):

[Guid("7710855F-D37B-464B-B645-972BAB2706D4")]  // Visual Studio умеет генерировать новые GUID-ы из коробки[InterfaceType(ComInterfaceType.InterfaceIsIUnknown)][ComVisible(true)]public interface IDebugApi

3) Реализую этот интерфейс, в виде класса DebugCOM:

[Guid("6AF9F5DD-6626-4E35-BEF4-29A73E18A739")][ComVisible(true)]public class DebugCOM : IDebugApi

4) Выношу отладочный интерфейс (без реализации) и все его зависимости в отдельный проект (Class Library), компилирую. Получаю DebugCOM.dll

5) С помощью утилиты tlbexp.exe из поставки Visual Studio (доступна через Developer Command Prompt) конвертирую DLL в TLB. В этом файле содержится полное описание интерфейсов, используемых типов данных и т.д.

Командная строка:

tlbexp DebugCOM.dll /out:DebugCOM.tlb

Если всё сделано правильно и все типы данных помечены как видимые для COM, то мы получим красивое сообщение:

Assembly exported to 'DebugCOM.tlb'

Иначе, нас будет ждать ад. Ад зависимостей:

TlbExp : warning TX801311B0 : Type library exporter warning processing 'AddressInfo.Type, DebugCOM'. Warning: Non COM visible value type 'SnesMemoryType' is being referenced either from the type currently being exported or from one of its base types.TlbExp : warning TX801311B0 : Type library exporter warning processing 'InteropBreakpoint.MemoryType, DebugCOM'. Warning: Non COM visible value type 'SnesMemoryType' is being referenced either from the type currently being exported or from one of its base types.TlbExp : warning TX801311B0 : Type library exporter warning processing 'IDebugApi.GetMemorySize(type), DebugCOM'. Warning: Non COM visible value type 'SnesMemoryType' is being referenced either from the type currently being exported or from one of its base types.TlbExp : warning TX801311B0 : Type library exporter warning processing 'IDebugApi.GetMemoryValue(type), DebugCOM'. Warning: Non COM visible value type 'SnesMemoryType' is being referenced either from the type currently being exported or from one of its base types.TlbExp : warning TX801311B0 : Type library exporter warning processing 'IDebugApi.SetMemoryValue(type), DebugCOM'. Warning: Non COM visible value type 'SnesMemoryType' is being referenced either from the type currently being exported or from one of its base types.TlbExp : warning TX801311B0 : Type library exporter warning processing 'IDebugApi.SetMemoryValues(type), DebugCOM'. Warning: Non COM visible value type 'SnesMemoryType' is being referenced either from the type currently being exported or from one of its base types.TlbExp : warning TX801311B0 : Type library exporter warning processing 'IDebugApi.SetMemoryState(type), DebugCOM'. Warning: Non COM visible value type 'SnesMemoryType' is being referenced either from the type currently being exported or from one of its base types.TlbExp : warning TX801311B0 : Type library exporter warning processing 'IDebugApi.GetMemoryState(type), DebugCOM'. Warning: Non COM visible value type 'SnesMemoryType' is being referenced either from the type currently being exported or from one of its base types.TlbExp : warning TX801311B0 : Type library exporter warning processing 'IDebugApi.GetMemoryAccessCounts(type), DebugCOM'. Warning: Non COM visible value type 'SnesMemoryType' is being referenced either from the type currently being exported or from one of its base types.TlbExp : warning TX801311B0 : Type library exporter warning processing 'IDebugApi.GetMemoryAccessCounts2(type), DebugCOM'. Warning: Non COM visible value type 'SnesMemoryType' is being referenced either from the type currently being exported or from one of its base types.

Видим, что тип данных SnesMemoryType не помечен как ComVisible(true). Исправляем.

6) Получившийся TLB-файл открываем (File->View TypeLib...) в ComView. Утилита находится здесь:

c:\Windows\Microsoft.NET\Framework\v4.0.30319\ComView.exe

Нам открывается окно просмотра нашего файла в виде уже сконвертированного IDL:

Жмём File->Save as... и сохраняем как IDL-файл.

7) Сгенерированный на предыдущем шаге IDL-файл добавляем в C++ проект, в котором мы, собственно, и будем обращаться к DebugCOM:

8) Теперь обращаемся к контекстному меню IDL-файла и жмём Compile Ctrl+F7. Если всё хорошо, мы получим два файла: DebugCOM_h.h и DebugCOM_i.c. Если же нет (у меня именно так и случилось), придётся решать ещё одну проблему.

Дело в том, что в C# порядок объявления типов и мест где они используются, совершенно не важен. Чего не скажешь про C/C++. Здесь пришлось упорядочивать объявления типов для C#.

9) Наконец-то получив долгожданные .h и .c файлы, инклудим их в наш код, и обращаемся к нужным методам отладочного интерфейса. Пример кода:

#include <atlbase.h>#include <iostream>#include "DebugCOM_h.h"#include "DebugCOM_i.c"int main(int argc, char* argv[]) {    HRESULT hr;    hr = ::CoInitializeEx(0, COINITBASE_MULTITHREADED);    if (FAILED(hr))    {        std::cout << "CoInitializeEx failure: " << std::hex << std::showbase << hr << std::endl;        return EXIT_FAILURE;    }    CLSID CLSID_server;    hr = ::CLSIDFromString(L"{6AF9F5DD-6626-4E35-BEF4-29A73E18A739}", &CLSID_server);    if (FAILED(hr))    {        std::cout << "CLSIDFromString failure: " << std::hex << std::showbase << hr << std::endl;        return EXIT_FAILURE;    }    CComPtr<IDebugApi> server;    hr = ::CoCreateInstance(CLSID_server, nullptr, CLSCTX_LOCAL_SERVER, __uuidof(IDebugApi), (void**)&server);    if (FAILED(hr))    {        std::cout << "CoCreateInstance failure: " << std::hex << std::showbase << hr << std::endl;        return EXIT_FAILURE;    }    DebugState state = {};    hr = server->GetState(&state);    if (FAILED(hr))    {        std::cout << "GetState failure: " << std::hex << std::showbase << hr << std::endl;        return EXIT_FAILURE;    }    std::cout << "PC Address: " << std::hex << std::showbase << state.Cpu.PC << std::endl;    ::CoUninitialize();    return EXIT_SUCCESS;    return 0;}

И здесь мы плавно подошли к особенностям использования COM.

Особенности COM-интерфейсов

Они бывают двух типов:

1. Inprocess
2. Out-of-process

• Первый тип используется, если требуется использовать COM в том же приложении, где уже есть реализация интерфейса. Например, я мог бы управлять отладчиком по COM из GUI, но не из IDA.
  Данный тип использует реализацию COM в виде DLL.

  
  

• Второй тип используется, если нужно иметь доступ к COM-интерфейсу извне приложения. В этом случае регистрируется исполняемый файл программы, который, к тому же, будет являться тем самым хост-приложением. Т.е. оно будет хранить состояние ядра, а COM поможет нам транслировать запросы.

  
  

Осталось найти описание того, как правильно регистрировать out-of-process COM. Оказалось, на GitHub есть самый что ни на есть "из первых рук" пример: https://github.com/dotnet/samples/tree/master/core/extensions/OutOfProcCOM. Он легко адаптируется и используется под нужды ваших проектов.

Выводы

В итоге, мне удалось подружить IDA Pro и .NET Framework приложение средствами Windows, не городя велосипеды из собственных RPC-протоколов. К тому же, я решил проблему наличия всего одной копии ядра эмулятора и шаринга его состояния между несколькими приложениями.

Библиотека концепций C++

template <список параметров>concept concept-name = constraint-expression;...<i>// concept</i>template <class T, class U>concept Derived = std::is_base_of<U, T>::value;

#include <string>#include <cstddef>#include <concepts>template<typename T>concept Sorter = requires(T a) {{ std::hash<T>{}(a) } -> std::convertible_to<std::size_t>;};struct asdf {};template<Sorter T>void f(T) {}int main() {using std::operators;f(abcs); <i>// Верно, std::string удовлетворяет условиям Sorter</i><i>//f(asdf{}); // Ошибка: asdf не удовлетворяет условиям Sorter</i>}

main.cpp: In function 'int main()':main.cpp:18:9: error: use of function 'void f(T) [with T = asdf]' with unsatisfied constraints18 | f(asdf{}); <i>// Ошибка: asdf не удовлетворяет условиям Sorter</i>|     ^main.cpp:13:6: note: declared here13 | void f(T) {}|   ^main.cpp:13:6: note: constraints not satisfiedmain.cpp: In instantiation of 'void f(T) [with T = asdf]':main.cpp:18:9:  required from heremain.cpp:6:9:  required for the satisfaction of 'Sorter<T>' [with T = asdf]main.cpp:6:18:  in requirements with 'T a' [with _Tp = asdf; T = asdf]main.cpp:7:21: note: the required expression 'std::hash<_Tp>{}(a)' is invalid7 |   { std::hash<T>{}(a) } -> std::convertible_to<std::size_t>|    ~~~~~~~~~~~~~~^~~cc1plus: note: set '-fconcepts-diagnostics-depth=' to at least 2 for more detail

template<typename T>concept Meshable = requires(T a, T b){a + b;};template<typename T>void f(T x){if constexpr(Meshable<T>){ <i>/*...*/</i> }else if constexpr(requires(T a, T b) { a + b; }){ <i>/*...*/</i> }}

Requires-expression

template<typename T>constexpr bool Movable = requires(T i) { i>>1; };bool b1 = Movable<int>; <i>// true</i>bool b2 = Movable<double>; <i>// false</i>Главный сценарий использования <i>requires-expression</i> состоит в создании концепций, просто проверить наличие нужных полей и методов внутри типа.template <typename T>concept Vehicle =requires(T v) { <i>// любая переменная m из концепции Vehicle</i>v.start();   <i>// обязательно должна обладать `v.start()`</i>v.stop();   <i>// и `v.stop()`</i>};

template <typename T>void smart_swap(T& a, T& b){constexpr bool have_element_swap = requires(T a, T b){a.swap(b);};if constexpr (have_element_swap) {a.swap(b);}else {using std::swap;swap(a, b);}}

Requires clause

template<typename T>void f(T&&) requires Eq<T>;template<typename T> requires Dividable<T>T divide(T a, T b) { return a/b; }

template <typename T>requires is_standard_layout_v<T> && is_trivial_v<T>void fun(T v);int main(){std::string s;fun(1); <i>// верно</i>fun(s); <i>// ошибка компиляции</i>}

template<typename T>requires Sumable<T>auto f1(T a, T b) requires Subtractable<T>; <i>// Sumable<T> && Subtractable<T></i>auto l = []<typename T> requires Sumable<T>(T a, T b) requires Subtractable<T>{};template<typename T>requires Sumable<T>class C;template<typename T>requires requires(T a, T b) {a + b;}auto f4(T x);

Модули

• заголовки, зависящие от порядка включения;
• утечка макросов из заголовочных файлов;
• повторная компиляция одного и того же кода;
• циклические зависимости;
• плохая инкапсуляция деталей реализации.

<i>//module.cpp</i>export module speech;export const char* get_phrase() {return Hello, world!;}<i>//main.cpp</i>import speech;import <iostream>;int main() {std::cout << get_phrase() << '\n';}

Сопрограммы

• оператор co_await для приостановки выполнения до возобновления;

task<> tcp_echo_server() {char data[1024];for (;;) {size_t n = co_await socket.async_read_some(buffer(data));co_await async_write(socket, buffer(data, n));}}

• ключевое слова co_yield для приостановки выполнения, возвращающего значение;

generator<int> iota(int n = 0) {while(true)co_yield n++;}

• ключевое слова co_return для завершения выполнения, возвращающего значение.

lazy<int> f() {co_return 7;}

Оператор KK

#include <set>struct Data{int i;int j;bool operator<(const Data& rhs) const {return i < rhs.i || (i == rhs.i && j < rhs.j);}};int main(){std::set<Data> d;d.insert(Data{ 1,2 });}

#include <set>#include <compare>struct Data{int i;int j;auto operator<=>(const Data& rhs) const = default;};int main(){Data d1{ 1, 4 };Data d2{ 3, 2 };d1 == d2;d1 < d2;d1 <= d2;std::set<Data> d;d.insert(Data{ 1,2 });}