Сборка софта для production -O2 vs -O0 -g

Мнение эникейщика:

Релиз всегда релиз, оптимизация и никаких отладочных символов (релизная версия). Если программа в «релизной версии» работает не стабильно, значит проблема в качестве кода.

если бы целевая платформа была не соляра, я бы посоветовала юзать Google Breakpad для отладки. ему и символы не нужны, и отладка удобная, и от юзера никаких навыков не требуется. но под Соляру мне не удалось его пропатчить. может, и можно, но долго и муторно.
что касается продакшн-специфичных ошибок: надо тестировать продакшн перед тем, как выкатывать версию юзерам.

При возникновении каких-либо неполадок можно взять бинарник с продакшена и отдебажить его (ведь отладочные символы вместе с ним: -g).

O_o
а сразу собирать две версии (релиз и дебаг) не ?
чтоб не «взять бинарник с продакшена и отдебажить его» потом

rpm сам тебе собирает debuginfo

бинарники просто пухнут от отладочной информации

В RPM что - не принято вырезать отладочные символы в отдельные пакеты?

Посоветуйте, что делать, пожалуйста.

core + отдельные отладочные символы + развернутые на девелоперской тачке сырцы решают проблему анализа сбоев.

-gsplit-dwarf и хранить отладочную информацию отдельно.

а сразу собирать две версии (релиз и дебаг) не ?

Это само собой разумеется. Но у нас процедура выкатывания пакета ну слишком долгая. По этому пытаюсь сократить «пинг-понг».

чтоб не «взять бинарник с продакшена и отдебажить его» потом

Это чтоб гарантировать, что испытываем один и тот же код.

rpm сам тебе собирает debuginfo

Это как? %debug_package? Чем оно поможет в данном случае? Какой юзкейс?

В RPM что - не принято вырезать отладочные символы в отдельные пакеты?

Принято, но можно обойти. http://fedoraproject.org/wiki/How_to_create_an_RPM_package#Miscellaneous_hints

-gsplit-dwarf

это кому такое? rpm, gcc?

Google Breakpad для отладки. ему и символы не нужны, и отладка удобная

чем это она удобная? Речь про minidump_stackwalk? По моему опыту почти бесполезная какаха, часто в стектрейсах бессмысленную ерунду выдаёт, да и документация не блещет. Может я не осилил, но всё же

В RPM что - не принято вырезать отладочные символы в отдельные пакеты?

Принято, но можно обойти

Хм. И зачем это обходить?

Это чтоб гарантировать, что испытываем один и тот же код.

для гарантии предназначены метки в системе контроля версий,

на вопрос твой основной может ответить только тестирование, собираем оптимизированную версию и собираем дебажную, прогоняем 100500 раз тест и замеряем перфоманс, если разница меньше 5% то и париться по этому поводу не стоит, если разница более 30% то можно и задуматься над переходом

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

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

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

Вот это я и хотел узнать.

Если ты решил спросить об этом у меня - зря.

Мне интересны агрументы и за и против. Честно говоря, хочется -O2 и без отладочных, но нужны причины.

Мне интересны агрументы и за и против.

За и против чего? Как решается проблема с отладочными символами - я написал, -O2 или -O0 - вообще не играет никакой роли.

-O2 или -O0 - вообще не играет никакой роли.

Зачем оно тогда надо?

Погуглил, таки играет.

Without any optimization option, the compiler's goal is to reduce the cost of compilation and to make debugging produce the expected results. Statements are independent: if you stop the program with a breakpoint between statements, you can then assign a new value to any variable or change the program counter to any other statement in the subprogram and get exactly the results you would expect from the source code.

-O2 или -O0 - вообще не играет никакой роли.

Зачем оно тогда надо?

/me покрутил пальцем у виска и уклонился от продолжения разговора

/me подозревал такой исход дискуссии...

-O2 -g

Честно говоря, хочется -O2 и без отладочных, но нужны причины.

Отправить отладочные символы в отдельный пакет религия не позволяет?

Прочитать тред религия не позволяет?

по дефолту у тебя собирается debuginfo (да, %debug_package). ставишь debuginfo через yum/dnf builddep PROG, и с помощью gdb/valgrind/etc. можно отлаживать корку.

-O3
Прошли те времена, когда оно глючило и падало.

-std=c11[c++11] -O3 -Wall -Werror -pedantic

Не собирается без варнингов - не готово в продакшен.

Мы собираем с "-O2 -g", и для тестирования, и для продакшена. Если на тестировании вылезает особо мрачная бага, то воспроизводим её на отельной сборке с "-O0" (реальная нужда возникает редко, трассировки рулят). Также с "-O0" собираются спецсборки для valgrind и для code coverage + unit tests.

Собирать для продакшена с "-O0" очень плохо для производительности, поскольку не делается инлайн тривиальных функций. Тот же stl адски тормозит. Хотя продакшн продакшену рознь, может вас и устроит десятикратно замедленная работа приложения.

-gsplit-dwarf и хранить отладочную информацию отдельно.

Мы отрезаем дебагифно посредством «objcopy --only-keep-debug» / «objcopy --strip-debug»

Тот же stl адски тормозит.

У нас сишка. Так что пока без этого. Да и самые большие зависоны происходят на работе с сетью. Но при этом приходится парсить файлы размером от 200 Мб, так что уже начинаю думать, как огранизовать перформанс ревью.

ставишь debuginfo через yum/dnf builddep PROG, и с помощью gdb/valgrind/etc.

Спасибо за информацию, буду пробовать

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

-O3 -Wall -Werror -pedantic

Не собирается без варнингов - не готово в продакшен.

Вот так и делаю, когда начинаю проекты. А легаси-говно, к сожалению, рефакторить опасно. По этому по мере возможностей варнинги (а точнее их причины) будут устраняться.

не готово в продакшен

Это еще только часть мучений: Package Verification (с стюардессами и покером, доморощенный), HP Quality Center (manual + automated testing), User Acceptance Testing, Production-like Environment Testing.

Сделай асинхронную работу с сетью и записи какое-нибудь кеширование.

от -O0 охеренно производительность просядет

Мудрые мужи правильно советуют дебаг от бинарников отделять. Если слишком круто, то можно дебаг оставить в бинарниках, но пожать gzip'ом (современный тулчейн умеет и понимает).

Продакшн на -O2 -g3.

Cделал. Правда пришлось помучаться с CMake. Хвала GCC, нашел письмо с рассылки: http://public.kitware.com/pipermail/cmake/2012-December/052890.html

Если вкратце, использую CPACK_RPM_USER_BINARY_SPECFILE и в темплейт спеки добавил две строчки:

%define _rpmfilename %%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm
%debug_package

Теперь вглубине _CPackPackages генерится 2 пакета, осталось только найти код, ответственный за копирование пакотов в $CMAKE_BINARY_DIR и оверрайднуть его, чтоб копировал оба пакета. Ибо сейчас ситуация такая:

$ find ./ -name '*.rpm'
./_CPack_Packages/Linux/RPM/foo-1.9.0-1.el6.x86_64.rpm
./_CPack_Packages/Linux/RPM/foo-debuginfo-1.9.0-1.el6.x86_64.rpm
./foo-1.9.0-1.el6.x86_64.rpm