ABI Dumper - Инструмент для создания дампа ABI из debug-информации ELF-объекта

Материал из Rosalab Wiki
Перейти к: навигация, поиск

При компиляции ELF-объектов, таких как разделяемые библиотеки, модули ядра Linux и др., с дополнительной опцией -g, в них добавляется отладочная информация. Эта информация обычно используется стандартным отладчиком gdb для предоставлению пользователю дополнительных возможностей при поиске ошибок во время выполнения программы. С помощью опции -debug-dump утилиты readelf или eu-readelf (из пакета elfutils) данная информация может быть представлена в удобном для прочтения виде.

Важной частью любого ELF-объекта является его бинарный интерфейс (ABI), предоставляемый использующим его приложениям. По-сути он является представлением API объекта на бинарном уровне (после компиляции). При обновлении ELF-объекта в дистрибутиве, важно поддерживать его ABI обратно совместимым, иначе это может привести к нарушению работы приложений. Изменения в ABI вызываются соответствующими изменениями в API объекта или изменением конфигурации сборки и опций компиляции. Чтобы отслеживать изменения в ABI объекта используется разработанный нами ранее инструмент ABI Compliance Checker. Но до настоящего времени он мог анализировать только разделяемые библиотеки посредством извлечения информации об ABI из заголовочных файлов.

Для того, чтобы расширить границы применения и успростить использование инструмента ABI Compliance Checker, мы разработали новый инструмент ABI Dumper для извлечения ABI-информации из отладочной информации объектов. Теперь, с помощью этого инструмента можно отслеживать изменения в ABI не только библиотек, но и, например, модулей ядра. Типичный пример использования заключается в создании дампов ABI для старой и новой версии объекта:

abi-dumper libtest.so.0 -o ABIv0.dump
abi-dumper libtest.so.1 -o ABIv1.dump

и последующем их сравнении:

abi-compliance-checker -l libtest -old ABIv0.dump -new ABIv1.dump

К сожалению, у данного подхода есть свои недостатки. Пожалуй, главным недостатком является невозможность проведения некоторых проверок совместимости. Например, нет возможности проверки изменений значений констант (как дефайнов, так и глобальных данных), так как эти значения подставляются в код при компиляции и отсутствуют в отладочной информации. В целом, могут быть проведены около 98 % всех проверок совместимости. Еще одним недостатком является долгое время работы на больших объектах размером более 50 мб. Для сжатия debug-информации и следовательно уменьшения размеров входных объектов может быть использована утилита dwz.

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.