Bug 19707
| Summary: | Автоматическая генерация debug-пакетов | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Konstantin Pavlov <thresh> |
| Component: | rpm | Assignee: | at <at> |
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | arseny, becase, boris, crux, enp, erthad, evg, glebfm, imz, kas, ktirf, lav, mike, php-coder, redbaron, wrar |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
| Bug Depends on: | |||
| Bug Blocks: | 24863 | ||
В SuSE, кажется, тоже было что-то подобное. Нерабочий proof of concept тут: http://git.altlinux.org/people/wrar/packages/rpm.git?p=rpm.git;a=shortlog;h=refs/heads/debuginfo (В ответ на комментарий №1)
> В SuSE, кажется, тоже было что-то подобное.
Это в дебиане "что-то подобное", во всех остальных rpm-baes дистрибутивах оно просто через rpm-4.2+
прошу обратить внимание на фич реквест, полезная же вещь! Вообще очень интересно, как можно что-то отлаживать, отлавливать ошибки, если нормальной возможности получить отладочный вывод для программы из собранного пакета. Дима, есть мысли на этот счёт? (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 Почему нерабочий? (В ответ на комментарий №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 из этого века. Спасибо Кириллу, beecrypt уже давно обновлён. Кто будет катить камень дальше? (In reply to comment #10) > Спасибо Кириллу, beecrypt уже давно обновлён. > Кто будет катить камень дальше? Я собирался после gcc4.5. Мужики, у нас же свой brp-strip, и он обрезает сильнее, чем в редхате (у нас используется 'strip --strip-unneeded', а в редхате используется 'eu-strip --strip-debug'). И в нём 100 тысяч миллионов опций. Так что надо всё переделывать, причем неизвестно как. А просто так коммитить новые файлы в наш rpm смысла нет. В лучшем случае мы получим пустые/некогерентные debuginfo пакеты. Принципиальный вопрос - надо ли обрезать .symtab. У нас .symtab всегда обрезается. В редхате .symtab не обрезается. Нет, американцы тоже .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 Мужики, короче я подумал, решил что надо делать отдельный *-debuginfo пакет на каждый подпакет, а пустых *-debuginfo пакетов делать не надо. И чтобы у каждого *-debuginfo пакета была зависимость на свой подпакет. А это не очень просто сделать. Так что кому надо просьба не беспокоиться. Я уже придумал как можно сделать. А то американцы насрут - всё в один пакет и без всяких зависимостей - и считается что круто. И ещё надо делать сделать замыкание *-debuginfo пакетов по завимостям. То есть чтобы была "сквозная отладка". А не так там что на одном фрейме отладка есть а на другом нету. И класть бы их хорошо в отдельный компонент, не classic. Мужики, я нарисовал сишную часть, лежит у меня в 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 для всего билдрута в целом, а другая на каждый пакет, которая будет выцеживать нужные файлы. Какие будут мнения.
Мужчины, я выложил бранч 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'а самим собой). (В ответ на комментарий №17)
> Бранч debuginfo собираем, его можно собрать в хешере два раза и посмотреть
> результат (который появится на второй раз в результате сборки rpm'а самим
> собой).
Пробовал собрать midori на x86_64. Создался пакет midori-debuginfo, но символы запаковались в /usr/lib/debug вместо /usr/lib64/debug и gdb их соотвественно автоматом не подхватывает.
В целом же фича просто потрясающая! Спасибо!
По-моему должно быть /usr/lib/debug на обеих архитектурах. (In reply to comment #19) > По-моему должно быть /usr/lib/debug на обеих архитектурах. Если /usr/lib/debug -- это префикс, за котором следует полный путь, включая %_libdir, то совершенно все равно, какой это префикс. На данном этапе есть возможность выбрать такой же префикс, как и у других. Лучше сделать как в редхате, если нет других соображений. Я проверил, 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 (In reply to comment #21) > Лучше сделать как в редхате, если нет других соображений. А какой префикс выбрали там? > Я проверил, gdb > действительно смотрит в /usr/lib64/debug (хотя в "info gdb" написано про > /usr/lib/debug). А valgrind - в /usr/lib/debug. Я помню, что valgrind у меня > подцепил debuginfo пакет... Префикс должен быть один для всех, кого-то из них придется исправить. В федоре везде /usr/lib/debug. Можно скачать какой-нибудь пакет и посмотреть. http://download.fedora.redhat.com/pub/fedora/linux/development/x86_64/debug/ В ubuntu/debian тоже /usr/lib/debug (В ответ на комментарий №24) > В ubuntu/debian тоже /usr/lib/debug Так там беарчь без извращений с /usr/lib64. Вроде бы уже есть? |
Description
Konstantin Pavlov 2009-04-21 18:25:03 MSD