19707 2009-04-21 18:25:03 +0400 Автоматическая генерация debug-пакетов 2011-03-09 14:29:09 +0300 1 1 4 Development Sisyphus rpm unstable all Linux CLOSED FIXED P3 enhancement --- 24863 1 thresh at at becase boris crux enp erthad evg glebfm imz kas ktirf lav ldv mike php-coder placeholder redbaron vt wrar qa-sisyphus oldest_to_newest 89845 0 thresh 2009-04-21 18:25:03 +0400 Нужна функция автоматической генерации debug-пакетов, аналогичная реализованной в Debian и Fedora. Подробности реализации в fedora можно посмотреть в их rpm 4.7 macros.in:166, scripts/find-debuginfo.sh. 89848 1 raorn 2009-04-21 19:26:22 +0400 В SuSE, кажется, тоже было что-то подобное. 90634 2 wrar 2009-05-03 22:02:56 +0400 Нерабочий proof of concept тут: http://git.altlinux.org/people/wrar/packages/rpm.git?p=rpm.git;a=shortlog;h=refs/heads/debuginfo 90635 3 wrar 2009-05-03 22:04:47 +0400 (В ответ на комментарий №1) > В SuSE, кажется, тоже было что-то подобное. Это в дебиане "что-то подобное", во всех остальных rpm-baes дистрибутивах оно просто через rpm-4.2+ 91434 4 redbaron 2009-05-18 20:16:57 +0400 прошу обратить внимание на фич реквест, полезная же вещь! 107523 5 lav 2010-03-08 20:24:23 +0300 Вообще очень интересно, как можно что-то отлаживать, отлавливать ошибки, если нормальной возможности получить отладочный вывод для программы из собранного пакета. 110517 6 kas 2010-07-12 16:33:17 +0400 Дима, есть мысли на этот счёт? 111031 7 ldv 2010-08-05 20:36:33 +0400 (In reply to comment #2) > Нерабочий proof of concept тут: > http://git.altlinux.org/people/wrar/packages/rpm.git?p=rpm.git;a=shortlog;h=refs/heads/debuginfo Почему нерабочий? 111032 8 wrar 2010-08-05 20:44:00 +0400 (В ответ на комментарий №7) > > Нерабочий proof of concept тут: > > http://git.altlinux.org/people/wrar/packages/rpm.git?p=rpm.git;a=shortlog;h=refs/heads/debuginfo > > Почему нерабочий? http://lists.altlinux.org/pipermail/devel/2009-May/170090.html Хочет beecrypt из этого века. 111056 9 kas 2010-08-07 07:32:47 +0400 http://lists.altlinux.org/pipermail/devel/2010-August/183683.html 112439 10 ldv 2010-09-21 14:41:48 +0400 Спасибо Кириллу, beecrypt уже давно обновлён. Кто будет катить камень дальше? 112563 11 kas 2010-09-22 23:29:46 +0400 (In reply to comment #10) > Спасибо Кириллу, beecrypt уже давно обновлён. > Кто будет катить камень дальше? Я собирался после gcc4.5. 116933 12 at 2011-01-08 04:58:50 +0300 Мужики, у нас же свой brp-strip, и он обрезает сильнее, чем в редхате (у нас используется 'strip --strip-unneeded', а в редхате используется 'eu-strip --strip-debug'). И в нём 100 тысяч миллионов опций. Так что надо всё переделывать, причем неизвестно как. А просто так коммитить новые файлы в наш rpm смысла нет. В лучшем случае мы получим пустые/некогерентные debuginfo пакеты. Принципиальный вопрос - надо ли обрезать .symtab. У нас .symtab всегда обрезается. В редхате .symtab не обрезается. 116934 13 at 2011-01-08 06:53:25 +0300 Нет, американцы тоже .symtab отрезают, я не так понял в одном месте. Надо придумать, как совместить brb-strip и debuginfo, чтобы это работало одинаково для всех пакетов - работало хорошо и с минимальным количеством опций. Дело в том что сейчас всякие опции в rpmbuild типа _strip_method или _strip_skiplist исходят из того, что бинарики собраны без -g. А если бинарики собраны с -g, то debug можно отрезать в любом случае. Короче смысол этих опций будет под вопросом. Предлагаю для обдумывания следующую модель brp-strip+debuginfo: каждый ELF executable и ELF shared в билдруте принудительно обрезается (и создается /usr/lib/debug$f.debug файл). Разница только сколько надо обрезать. По умолчанию режим обрезания "debug,comment,symbols". Со стороны rpmbuild можно только изменить сколько надо обрезать, например, так: %название_макроса_обрезания шелл-паттерн сколько-обрезать E.g. # keep symbols %название_макроса_обрезания %_libdir/valgrind/*.so debug,comment 116954 14 at 2011-01-08 21:13:05 +0300 Мужики, короче я подумал, решил что надо делать отдельный *-debuginfo пакет на каждый подпакет, а пустых *-debuginfo пакетов делать не надо. И чтобы у каждого *-debuginfo пакета была зависимость на свой подпакет. А это не очень просто сделать. Так что кому надо просьба не беспокоиться. Я уже придумал как можно сделать. А то американцы насрут - всё в один пакет и без всяких зависимостей - и считается что круто. И ещё надо делать сделать замыкание *-debuginfo пакетов по завимостям. То есть чтобы была "сквозная отладка". А не так там что на одном фрейме отладка есть а на другом нету. 116956 15 mike 2011-01-08 23:09:11 +0300 И класть бы их хорошо в отдельный компонент, не classic. 116966 16 at 2011-01-09 10:53:03 +0300 Мужики, я нарисовал сишную часть, лежит у меня в rpm.git бранч debuginfo. Работает пока примерно так: LD_LIBRARY_PATH=$PWD/build/.libs rpmbuild --define '__find_debuginfo_files while read -r f; do f=${f#$RPM_BUILD_ROOT}; if [ -f $RPM_BUILD_ROOT/usr/lib/debug$f.debug ]; then echo /usr/lib/debug$f.debug; fi; done' -bb --short-circuit *.spec То есть там будет две стадии - одна brp-debuginfo для всего билдрута в целом, а другая на каждый пакет, которая будет выцеживать нужные файлы. Какие будут мнения. 117161 17 at 2011-01-14 08:24:26 +0300 Мужчины, я выложил бранч debuginfo, там реализована мегафича - автоматическое удаление дупов исходников между *-debuginfo подпакетами. На основе зависимостей между основными подпакетами! Например, если пакет rpm требует пакет librpm, то из пакета rpm-debuginfo можно удалить пересекающиеся исходники, добавив зависимость на librpm-debuginfo. А пакет rpm-static требует пакет rpm. Тогда, по этой же логике, из пакета rpm-static-debuginfo можно удлить исходники, пересекающиеся с rpm-debuginfo, и добавить зависимость на rpm-debuginfo. Но rpm в свою очередь требует librpm. Так что в пакете rpm-static-debuginfo по идее может вообще не остаться исходников! Бранч debuginfo собираем, его можно собрать в хешере два раза и посмотреть результат (который появится на второй раз в результате сборки rpm'а самим собой). 117248 18 crux 2011-01-18 11:30:59 +0300 (В ответ на комментарий №17) > Бранч debuginfo собираем, его можно собрать в хешере два раза и посмотреть > результат (который появится на второй раз в результате сборки rpm'а самим > собой). Пробовал собрать midori на x86_64. Создался пакет midori-debuginfo, но символы запаковались в /usr/lib/debug вместо /usr/lib64/debug и gdb их соотвественно автоматом не подхватывает. В целом же фича просто потрясающая! Спасибо! 117249 19 at 2011-01-18 11:33:40 +0300 По-моему должно быть /usr/lib/debug на обеих архитектурах. 117265 20 ldv 2011-01-18 15:40:49 +0300 (In reply to comment #19) > По-моему должно быть /usr/lib/debug на обеих архитектурах. Если /usr/lib/debug -- это префикс, за котором следует полный путь, включая %_libdir, то совершенно все равно, какой это префикс. На данном этапе есть возможность выбрать такой же префикс, как и у других. 117267 21 at 2011-01-18 15:54:47 +0300 Лучше сделать как в редхате, если нет других соображений. Я проверил, gdb действительно смотрит в /usr/lib64/debug (хотя в "info gdb" написано про /usr/lib/debug). А valgrind - в /usr/lib/debug. Я помню, что valgrind у меня подцепил debuginfo пакет... $ strings /usr/bin/gdb |grep /debug /usr/lib64/debug $ rpm -ql valgrind |xargs strings |grep /debug m_debuginfo/debuginfo.c /usr/lib/debug%s/%s /usr/lib/debug/.build-id/%c%c/%s.debug Да, подразумевается, что /usr/lib/debug - это префикс, за которым следует полный путь - будет выполняться что-то вроде eu-strip -f /usr/lib/debug$f.debug $f 117276 22 ldv 2011-01-18 16:39:39 +0300 (In reply to comment #21) > Лучше сделать как в редхате, если нет других соображений. А какой префикс выбрали там? > Я проверил, gdb > действительно смотрит в /usr/lib64/debug (хотя в "info gdb" написано про > /usr/lib/debug). А valgrind - в /usr/lib/debug. Я помню, что valgrind у меня > подцепил debuginfo пакет... Префикс должен быть один для всех, кого-то из них придется исправить. 117278 23 at 2011-01-18 16:47:45 +0300 В федоре везде /usr/lib/debug. Можно скачать какой-нибудь пакет и посмотреть. http://download.fedora.redhat.com/pub/fedora/linux/development/x86_64/debug/ 117283 24 crux 2011-01-18 18:18:26 +0300 В ubuntu/debian тоже /usr/lib/debug 117284 25 wrar 2011-01-18 18:24:25 +0300 (В ответ на комментарий №24) > В ubuntu/debian тоже /usr/lib/debug Так там беарчь без извращений с /usr/lib64. 119102 26 becase 2011-03-09 14:29:09 +0300 Вроде бы уже есть?