из visa.so сделать visa.a

Нет. Там потеря инфы. A – это архив из объектников. А so – уже продукт их обработки и склеивания. Шарда ближе к исполняемым файлам по своей сути.

а возможно-ли провернуть сабжевый финт ушами? а-то статическая библиотека не распростаняется и код (от National Intruments) проприетарный…

И в чём проблема в so, кстати? Разницы же нет никакой.

код (от National Intruments)

Если речь про LabVIEW, то его уже метапрог заменил на свою альтернативу, можно у него сорц спросить. Правда в картинках.

%)))

не, LabVIEW народ на винде юзает, а мне нужно драйвер девайся оформить для линукса

И в чём проблема в so, кстати?

[  3%] Linking CXX executable ../../UnmAccessTest
CMakeFiles/UnmAccessTest.dir/UnmAccessTest.cpp.o: In function `ChOpen(unsigned int*, char*, int)':
UnmAccessTest.cpp:(.text+0x32): undefined reference to `unmbase_init'
CMakeFiles/UnmAccessTest.dir/UnmAccessTest.cpp.o: In function `ChClose(unsigned int)':
UnmAccessTest.cpp:(.text+0x191): undefined reference to `unmbase_close'
CMakeFiles/UnmAccessTest.dir/__/funcs/utils.cpp.o: In function `checkError(unsigned int, int, int)':
utils.cpp:(.text+0x6a): undefined reference to `unmbase_error_message'
CMakeFiles/UnmAccessTest.dir/__/funcs/utils.cpp.o: In function `selectDevice(int, char**, char*, bool*, int*)':
utils.cpp:(.text+0x4fd): undefined reference to `viOpenDefaultRM'
utils.cpp:(.text+0x544): undefined reference to `viFindRsrc'
utils.cpp:(.text+0x58a): undefined reference to `viOpen'
...

Разницы же нет никакой.

по-ходу, что-то делаю не так...

а мне нужно драйвер девайся оформить для линукса

Если не ошибаюсь, то тогда и статическая либа не прокатит. Т.к. там надо конпелять с головами Linux и вообще как-то особо.

UnmAccessTest.cpp:(.text+0x32): undefined reference to `unmbase_init’

Не хватает ещё чего-то. Какой-то либы. Или объектника.

ок, буду копать...
пасиба за указание направления для разборок! :)

Есть ещё вероятность, что функции, которые не находятся, это «колл бэки» которые либа ожидает, что заимплементишь ты в своём бинарники. Во-времена, когда колбаса была вкусной, а небо темно от птеродактилей - это была относительно распространённая техника, настоятельно рекомендую - изучить таблицу импорта библиотеки, если хидеров и доки совсем уж нет.

сам visa.h есть, и callback можно установить, но эта техника в портируем коде не используется...

Тогда ldd soname.so :)

попробуй разобрать .so с помощью objdump -d Получишь листинг на ассемблере. Скорее всего тебе нужны только сегменты .text и .rodata. Последний просто сдампи - там всякие статические данные типа строк, констант и пр. Оставь в этом всём только ассемблер и данные и попробуй собрать .a

Есть ещё radare2 например, оно несколько более готовый для компиляции код выдаёт.

Если ограничиться только используемыми тобой функциями и они не используют все остальные, то, возможно, это не так геморройно будет, как может показаться.

Там потеря инфы

Что-то теряется, да. Но насколько эта информация важна?

:))

показывает только стандартные библиотеки...

спасиюо, плпробую...

// а пока - спать, двое суток без сна некошерно %)

Заменил? Метапрог на нём же написан, поэтому для использования надо этот лабвью пиратить.

Что-то теряется, да. Но насколько эта информация важна?

Если писать код для разделяемой библиотеки, то hw (прим.: переменная хелловорд) при ассемблировании будет транслировано в простое число. Но в момент загрузки библиотеки происходят перемещения секций и это число уже будет неактуальным. Поэтому используется форма записи относительно GOT (прим.: global offset table). Переменная hw@GOTPCREL - это указатель на данные, расположенные по метке hw. Запись hw@GOTPCREL(%rip) позволяет не беспокоится ни о чём. Просто: там где в исполняемом файле вы бы записали movq $x, %reg для разделяемой библиотеки стоит писать movq x@GOTPCREL, %reg.

Наверное всё-таки movq x@GOTPCREL(%rip), %reg

В общем разница уже на уровне машинных кодов.

GOTPCREL

То же самое будет и в статической библиотеке, если код собирать с -fPIC. Из статической библиотеки, которая собрана в позиционно-зависимом режиме, нельзя сделать динамическую. Но динамические всегда позиционно-независимые, и поэтому принципиальных проблем в обратном преобразовании быть не должно. Нет?

Можно, пожалуй, сделать обёртку, которая сделает (руками) dlopen-from-memory (если повезёт, то и in-place) и будет передавать вызовы/результаты. Сама исходная .so попадёт внутрь .а как монолитный участок (либо прямо образ файла, либо выровненное по странице представление того, как должны выглядеть загруженные сегменты), на старте (CTOR_LIST) обёртка пройдётся по нужным местам mprotect’ом и всё станет хорошо.

Для DLL есть готовый MemoryModule, а для ELF мне не попадалось ничего.

хотя благодаря -fPIC/got может даже получиться раздёргивание на .text и .[ro]data с успешной линковкой в .text и .data основной программы (что для DLL было бы без шансов)

а для ELF мне не попадалось ничего.

memfd_create + dlopen("/proc/$$/fd/$fd").
Несколько лет назад проскакивал блогпост, где автор попробовал так, и у него получилось.

Скорее всего тебе нужны только сегменты .text и .rodata

Динамические библиотеки ещё активно завязаны на .plt и .got. На их основе линкером формируется динамическая таблица символов. Так что просто так слинковаться не выйдет, придётся переизобретать часть кишок ld-linux.so

Да, помню там автор даже показывал как выполнить бинарь из данных полностью минуя VFS. Очень удобно для малвари.

А я не про слинковаться. Я про получить ассемблерный листинг кода, найти нужные функции, привести в компилируемый вид и скомпилировать ассемблером. Скомпилированный из сырцов код чаще всего только в .text Во всяких прочих - может быть то, что уже линкер подтянул из всяких crt0 и т.п.

То же самое будет и в статической библиотеке, если код собирать с -fPIC. Из статической библиотеки, которая собрана в позиционно-зависимом режиме, нельзя сделать динамическую.

Не знаю насчёт -fPIC статики. Может её только с PIE можно линковать. А может и всё ок.

Но динамические всегда позиционно-независимые, и поэтому принципиальных проблем в обратном преобразовании быть не должно. Нет?

Тут вопрос в сложности процесса. Если он приближается к reverse ingeniring-у, то это провал для более менее сложной либы.

Вообще в объектнике есть набор символов, и линкер всё лишнее выкидывает, оставляя только то, что нужно шарде. Там остаются нужные функции. И всё остальное. Что-то меняется на числовые значения, возможно. В теории можно преобразовать, но уже не в набор объектников, а в один объектник. Вопрос в сложности процесса.

Заменил? Метапрог на нём же написан, поэтому для использования надо этот лабвью пиратить.

Да, не. Это всё злые языки. Там цикл Карно-Менделеева-Клапейрона-Метапрога-Таненбаума-Торвальдса. Он пишет Метапрог на Лабвью. И потом пишет Лабвью на Метапроге, потому что Мтапрог ещё сырой. И дорабатывает Меатпрог. Потом запускает его и Лабвью не нём. Цикл.

Иначе ворох потраченного времени и отсутствие прогресса, одновременно с довольством собой автора не объяснить.

«Влинковать» сошку в бинарь можно, думаю. Только как это поможет? Если есть уверенность, что все либы на месте (видимо проблемы со сборкой?), то можно проигнорить все undefined reference:

gcc ... -Wl,--unresolved-symbols=ignore-all

но потом или бинарь запускать с LD_PRELOAD=… ./a.out или его подкорректировать через какой-нибудь patchelf.

Еще можно пометить все неразрешенные символы как WEAK т.е. переразмещение будет линивое, во время вызова, возможно символ вовсе не потребуется ибо «ту менюшку я не открываю». Изнутри кода это делается примерно так:

void f(void) __attribute__ ((weak));

но должны быть способы и снаружи, опции линкеру смотреть, на крайняк можно уже и бинарь подправить.

// у всех прошу прощения, что поднял тему и слинял - решал другие проблемки по этому же проекту...

а линковка падает так:

/usr/bin/c++      CMakeFiles/UnmAccessTest.dir/UnmAccessTest.cpp.o CMakeFiles/UnmAccessTest.dir/__/__/linux-wrappers/linux-wrappers.cpp.o CMakeFiles/UnmAccessTest.dir/__/funcs/utils.cpp.o  -o ../../UnmAccessTest  -L/usr/lib/x86_64-linux-gnu/libvisa.so -Wl,-rpath,/usr/lib/x86_64-linux-gnu/libvisa.so -rdynamic ../../libChFuncs.a ../../libunmuem.a -Wl,-Bstatic -lunmbase -Wl,-Bdynamic 
CMakeFiles/UnmAccessTest.dir/UnmAccessTest.cpp.o: In function `ChOpen(unsigned int*, char*, int)':
UnmAccessTest.cpp:(.text+0x32): undefined reference to `unmbase_init'
CMakeFiles/UnmAccessTest.dir/UnmAccessTest.cpp.o: In function `ChClose(unsigned int)':
UnmAccessTest.cpp:(.text+0x191): undefined reference to `unmbase_close'
CMakeFiles/UnmAccessTest.dir/__/funcs/utils.cpp.o: In function `checkError(unsigned int, int, int)':
utils.cpp:(.text+0x6a): undefined reference to `unmbase_error_message'
CMakeFiles/UnmAccessTest.dir/__/funcs/utils.cpp.o: In function `selectDevice(int, char**, char*, bool*, int*)':
utils.cpp:(.text+0x4fd): undefined reference to `viOpenDefaultRM'
... и мого еще всякого интересного ...

Что-то у вас тут беседа не задалась, почему до сих пор никто не пошутил что «для всего остального есть mastercard»

про обертку уже вроде написали.

Так это вроде зависимости от мелкомягкого MFC, глянул на проекты, которые юзают viOpenDefaultRM, там хидер инклудился afx.h. Ну тут по идее через Wine надо.

вообше, идей много, спасибо огромное! :)

но как оно обычто и бывает - главная проблема сидит за монитором %)

в CMake есть был такой кусок:

 74         if (WIN32)                                                               
 75             target_link_libraries(${__target} unmbase_32.lib visa32.lib winmm)   
 76         else (WIN32)                                                             
 77             target_link_libraries(${__target} libunmbase.a)                 
 78         endif (WIN32)

kostyarin_