Таблица экспорта so linux

Изучение разделяемых библиотек (so)

Для того что бы выяснить какие функции экспортирует закрытая разделяемая библиотека (.so) и на основе этого написать свой C/C++ хидер (.h) воспользуемся двумя командами из пакета binutils. Поскольку формат ELF файлов не отличается для разных архитектур, то можно даже не устанавливать кросс утилиты.

Первая необходимая нам команда — readelf — позволяет получить самую разнообразную информацию о исполнимом файле или разделяемой библиотеки. Подробности можно узнать man elf , нас же на данном этапе интересует только таблица символических имён (symbols) библиотеки. Извлечь её можно дав команду

readelf -s -W libyourlibrary.so

Здесь ключ -s указывает, что нам нужна именно таблица имён (symbols), а ключ -W заставляет не обрезать выводимые данные под ширину терминала.

Таблицу с именами мы получаем в следующем виде:

 Num: Value Size Type Bind Vis Ndx Name 42: 42c11768 24 FUNC GLOBAL DEFAULT 10 _ZNK10CAM_Engine15isCameraRunningEv 43: 00000000 152 FUNC GLOBAL DEFAULT UND _ZN5QFileD1Ev 

Имена у которых поле ‘Value’ равно нулю или поле ‘Ndx’ равно UND являются внешними по отношению к библиотеке, т.е. используются функциями библиотеки, но должны импортироватся из других библиотек. Их нам тоже необходимо будет отсечь.

Само имя функции переменной и т.п. содержится в последнем столбце. Имена используемые чистым C записываются как есть. Поскольку в C++ существуют пространства имён, классы, перегрузка функции из имени в таблицы мы можем извлечь много полезной информации. В частности это список параметров.

Имена кодируются специальным образом (mangling) и имеют малочитаемый вид. Что бы расшифровать имя, воспользуемся командой c++filt .

Что бы отсечь имена не экспортируемые библиотекой, отфильтруем вывод readelf с помощью скрипта awk . В итоге мы получаем цепочку команд:

readelf -s -W libezxcameraengine.so | awk '< if($2) print $8 "\t\t // " $4 >' | c++filt | sort 

На выходе мы получим отсортированный список всех функций и переменных в виде пригодном для копирования в заголовочный файл.

К сожалению, не существует простого способа узнать тип возвращаемого значения. Тут поможет анализ бинарного кода, но в большинстве случаев нужный тип можно угадать 😉

И наконец для имён функций в формате чистого C необходимые параметры можно узнать только анализом бинарного кода.

Для обзора экспортируемых и используемых функций воспользуемся командой:

readelf -s -W libezxbluetooth.so | c++filt | sort -k 8 

Список так же будет отсортирован по именам функций/переменных.

objdump -dR libezxbluetooth.so | c++filt 

дизассемблирует бинарный код. Это конечно если у вас в системе установлен мультиархитектурный objdump. Иначе воспользуйтесь дампером из тулкита /arm-eabi/bin/arm-linux-gnueabi-objdump

Источник

Хочу разобраться с таблицами экспорта в C/C++ библиотеках/исп. файлах.

Интересуют платформы: linux, windows, macOS. Последние 2 знаю хуже. Меня интересуют не спецификации или «как правильно», а как оно в реальности и какие есть побочные явления/возможности. Что я помню:

Компилятор выдаёт один объектный файл на каждую единицу трансляции — .cpp файл с кучей включенных .h. В этот объектный файл попадает таблица экспорта — набор «символов» (строк/имён) с атрибутами и адресом для каждого символа. Имена функций, глобальных переменных и т.п. Адрес — всмысле по какому смещению от адресного пространства процесса или какой-то секции (напр. секции кода, секции данных) данный символ будет лежать в памяти. Атрибуты — это код/данные/другое.

Когда из набора объектных файлов линкуется один .so/.dll/.a/.exe, наши таблицы экспорта из всех объектных файлов тупо сливаются в одну. Если какой-то символ где-то дублируется, линкер матерится (как оно под разными платформами)?

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

Сколько в каждом .obj / .so / .dll — файле таблиц экспорта? Одна на весь файл или у неё существуют разные разделы?

C++ — классы выступают как пространства имён для «символов». Плюс сами namespace-ы. Для них есть какие-то правила формирования имён символов или каждый компилятор заворачивает двойные двоеточия («::») как-то по-своему?

Что сделать в C/C++ — программе, чтобы обеспечить символу присутствие в таблице экспорта? Это будет любая функция или функция-член класса и любая глобальная переменная? Правильно я понимаю, что static глобальные переменные не попадут в таблицу экспорта, обеспечивая локальность символа для данной единицы трансляции? А если надо заюзать глобальную переменную из другой единицы трансляции, то нужно объявить эту переменную со словом extern?

Я гарантированно где-то неправ, т.к. давно не думал об этом, поправьте/дополните пожалуйста. Плюс интересно почитать что-нибудь касающееся сабжа, но что у меня не упомянуто и особо интересно почитать о различиях линковальной кухни под разными платформами, о платформенно-зависимых ключевых словах языков C/C++ под разными платформами: о виндовых «__declspec(dllexport)» и прочей такой тряхомути.

Что такое hidden visibility в gcc? Ладно, погуглю. )

Источник

Просмотр экспорта библиотеки

Как можно выцепить из библиотеки список экспортируемых функций?

Re: Просмотр экспорта библиотеки

Re: Просмотр экспорта библиотеки

а теперь представим себе ситуацию, что это по какой-либо причине сделать нельзя. Что делать тогда?

Re: Просмотр экспорта библиотеки

Re: Просмотр экспорта библиотеки

если же она стрипнутая, то

те, что UND — импортируемые [внешние]. те, что с индексом — экспортируемые [внутренние].

Re: Просмотр экспорта библиотеки

тупо парсить вывод nm -D, или использовать libbfd

Re: Просмотр экспорта библиотеки

Re: Просмотр экспорта библиотеки

экспортируемые символы - это те, что определены или которые можно использовать? если вторые, то для них BIND = WEAK/GLOBAL, VISIBILITY = DEFAULT

Re: Просмотр экспорта библиотеки

> экспортируемые символы — это те, что определены или которые можно использовать? если вторые, то для них BIND = WEAK/GLOBAL, VISIBILITY = DEFAULT

ну через секцию «.symtab» экспортируются все символы — и глобальные и локальные. таким образом, при наличии этой секции и определённом желании можно использовать и не только GLOBAL 🙂

но вообще конечно да, экспортируемые — это GLOBAL/WEAK определённые в текущем объектном файле.

Похожие темы

• Форум экспорт NFS проблема! (2009)
• Форум как откомпилить файл с библиотекой (2005)
• Форум Как получить список экспортируемых функции библиотеки? (2010)
• Форум Клиент MPD, экспорт библиотеки (2010)
• Форум Экспорт из динамической библиотеки (2007)

• Форум Поиск исполняемого кода нативного метода в библиотеке *.so (2018)
• Форум Поддержка ACL при экспорте каталогов по NFS (2008)
• Форум загрузка(average) CPU% (2006)
• Форум Как сохранить аттач (2002)
• Форум сборка .so, экспорт только выбранных функций/переменных (2008)

Источник

How do I find out what all symbols are exported from a shared object?

All symbols in the object are exported — even the «internal» functions. You just have to declare them to the compiler so that they’ll be ready for the linker. This is usually done with a header file, like Ryan Fox said below.

Chris Lutz is mistaken: not all symbols are exported from relocatable object files, much less from shared libraries.

9 Answers 9

Do you have a «shared object» (usually a shared library on AIX), a UNIX shared library, or a Windows DLL? These are all different things, and your question conflates them all 🙁

• For an AIX shared object, use dump -Tv /path/to/foo.o .
• For an ELF shared library, use readelf -Ws —dyn-syms /path/to/libfoo.so , or (if you have GNU nm) nm -D /path/to/libfoo.so .
• For a non-ELF UNIX shared library, please state which UNIX you are interested in.
• For a Windows DLL, use dumpbin /EXPORTS foo.dll .

Very helpful, good to have such overview. nm also works on MacOSX, except the -D option. Or brew install binutils and use the GNU version via gnm . For GNU nm , —demangle is also useful. Also gobjdump .

Actually, you can work both with shared libraries, dlls, and object filles from a single utility just fine, see this answer.

I suppose there is no API to do this in runtime, right? I’ve found that on windows you have GetProcAddress() but you can’t use it without actually executing the library (which is very dangerous if the parent app has too much access rights).

objdump is another good one on linux.

If it is a Windows DLL file and your OS is Linux then use winedump:

$ winedump -j export pcre.dll Contents of pcre.dll: 229888 bytes Exports table: Name: pcre.dll Characteristics: 00000000 TimeDateStamp: 53BBA519 Tue Jul 8 10:00:25 2014 Version: 0.00 Ordinal base: 1 # of functions: 31 # of Names: 31 Addresses of functions: 000375C8 Addresses of name ordinals: 000376C0 Addresses of names: 00037644 Entry Pt Ordn Name 0001FDA0 1 pcre_assign_jit_stack 000380B8 2 pcre_callout 00009030 3 pcre_compile . 

On *nix check nm. On windows use the program Dependency Walker

Specifically, nm —defined-only -g something.so will print the symbols that are both defined in the library and extern symbols, which is probably what the OP wants.

GNU nm lists the symbols from object files objfile. If no object files are listed as arguments, nm assumes the file a.out.

The cross-platform way (not only cross-platform itself, but also working, at the very least, with both *.so and *.dll ) is using reverse-engineering framework radare2. E.g.:

$ rabin2 -s glew32.dll | head -n 5 [Symbols] vaddr=0x62afda8d paddr=0x0005ba8d ord=000 fwd=NONE sz=0 bind=GLOBAL type=FUNC name=glew32.dll___GLEW_3DFX_multisample vaddr=0x62afda8e paddr=0x0005ba8e ord=001 fwd=NONE sz=0 bind=GLOBAL type=FUNC name=glew32.dll___GLEW_3DFX_tbuffer vaddr=0x62afda8f paddr=0x0005ba8f ord=002 fwd=NONE sz=0 bind=GLOBAL type=FUNC name=glew32.dll___GLEW_3DFX_texture_compression_FXT1 vaddr=0x62afdab8 paddr=0x0005bab8 ord=003 fwd=NONE sz=0 bind=GLOBAL type=FUNC name=glew32.dll___GLEW_AMD_blend_minmax_factor 

As a bonus, rabin2 recognizes C++ name mangling, for example (and also with .so file):

$ rabin2 -s /usr/lib/libabw-0.1.so.1.0.1 | head -n 5 [Symbols] vaddr=0x00027590 paddr=0x00027590 ord=124 fwd=NONE sz=430 bind=GLOBAL type=FUNC name=libabw::AbiDocument::isFileFormatSupported vaddr=0x0000a730 paddr=0x0000a730 ord=125 fwd=NONE sz=58 bind=UNKNOWN type=FUNC name=boost::exception::~exception vaddr=0x00232680 paddr=0x00032680 ord=126 fwd=NONE sz=16 bind=UNKNOWN type=OBJECT name=typeinfoforboost::exception_detail::clone_base vaddr=0x00027740 paddr=0x00027740 ord=127 fwd=NONE sz=235 bind=GLOBAL type=FUNC name=libabw::AbiDocument::parse 

Works with object files too:

$ g++ test.cpp -c -o a.o $ rabin2 -s a.o | head -n 5 Warning: Cannot initialize program headers Warning: Cannot initialize dynamic strings Warning: Cannot initialize dynamic section [Symbols] vaddr=0x08000149 paddr=0x00000149 ord=006 fwd=NONE sz=1 bind=LOCAL type=OBJECT name=std::piecewise_construct vaddr=0x08000149 paddr=0x00000149 ord=007 fwd=NONE sz=1 bind=LOCAL type=OBJECT name=std::__ioinit vaddr=0x080000eb paddr=0x000000eb ord=017 fwd=NONE sz=73 bind=LOCAL type=FUNC name=__static_initialization_and_destruction_0 vaddr=0x08000134 paddr=0x00000134 ord=018 fwd=NONE sz=21 bind=LOCAL type=FUNC name=_GLOBAL__sub_I__Z4funcP6Animal 

Источник