У меня есть двоичная библиотека и двоичный исполняемый файл, использующий эту библиотеку, оба написанные на C. Я знаю C API, предоставляемый библиотекой, но ни источник библиотеки, ни исполняемый файл.Я хотел бы понять, как исполняемый файл использует библиотеку (сравните мой предыдущий вопрос Как узнать, какие функции библиотеки вызываются программой ).
Предлагаемые решения не дали удовлетворительных результатов.Кажется, что не упоминается возможность реализовать библиотеку-оболочку, которая имитирует известный интерфейс бинарной библиотеки, в которой я заинтересован. Моя идея - перенаправить все вызовы-оболочки в двоичную библиотеку.Это должно позволить мне регистрировать все вызовы и переданные параметры, другими словами, для инструментов библиотеки.
Мне удалось реализовать библиотеку оболочки в Linux как библиотеку динамических ссылок (* .so) вместе с моим собственным примером приложения, подключающимся к оболочке.Оболочка, в свою очередь, использует оригинальную двоичную библиотеку.Обе библиотеки используются с dlopen и dlsym для доступа к API.Однако я сталкиваюсь со следующей практической проблемой: мне не удается связать исходный двоичный исполняемый файл с моей библиотекой-оберткой.Это связано с тем, что исполняемый файл ожидает библиотеку под определенным именем.Однако, если я назову свою библиотеку рэперов таким образом, она конфликтует с исходной библиотекой.Удивительно (для меня) просто переименовать .so-файл этого и связать библиотеку оболочки с ним не работает (Результат останавливается без сообщения об ошибке, когда библиотека оболочки вызывает dlopen, и я не получаю больше информации от отладчикачем это происходит в malloc).
Я пробовал несколько вещей, таких как использование символических ссылок, чтобы переместить одну из библиотек из пути поиска компоновщика во время выполнения, чтобы добавить путик переменной среды LD_LIBRARY_PATH различные относительные местоположения .so-файлов (и соответствующие пути для dlopen), а также различные параметры компилятора, пока безуспешно.
Подводя итог, хотелось бы
(executable)_orig->(lib.so)->(lib.so)_orig
, где (executable)_orig и (lib.so)_orig (оба двоичных файла, на которые я не могу влиять) таковы, что
(executable)_orig->(lib.so)_orig
работает,У меня есть источники (lib.so), и я могу изменить его по своему желанию.Также я могу модифицировать хост-систему Linux так, как мне нравится.Задача (lib.so) - рассказать, как взаимодействуют (executable)_orig и (lib.so)_orig.
У меня также работает
(executable)->(wrapper.so)->(lib.so)_orig
, что, по-видимому, указывает на то, что проблема связана ссоглашения об именах и загрузке для библиотек.
Это отдельный новый вопрос, поскольку он касается конкретной практической проблемы, описанной выше.Кроме того, некоторая справочная информация о том, почему переименование файла, соответствующего (lib.so)_orig, может обойти проблему, также может оказаться полезной.