GCC эквивалент PDB

Question

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

Что эквивалентно выполнению этогос GCC?Я могу сгенерировать трассировку стека, но если я хочу, чтобы это было полезно, необходимо, чтобы символы отладки были скомпилированы в исполняемый файл (с -g).Очевидно, что это неприемлемо для распространения релиза, так как исполняемый файл может немного увеличиваться в размере.

Я немного погуглил и обнаружил ссылки на возможность objcopy выделять символы отладки в отдельный файл, но эта страница подразумевалаМне по-прежнему нужно иметь доступ к символам отладки вместе с исполняемым файлом релиза, что, опять же, явно неприемлемо.

Answer 1

Ну, идея в том, что вы компилируете с -g, чтобы добавить символы отладки, но не замедлить работу программы, т.е. большинство программ будет делать -g -O2, тогда вы можете отделить символы отладки с помощью objdump. После этого вы можете strip собрать релиз, чтобы в нем не было символов отладки.

Обновление: последние GDB поддерживает отдельные файлы отладки, см. https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html

Например, вы можете сделать

objcopy --only-keep-debug prog prog.debug
strip prog

Теперь у вашего prog не будет отладочных символов. Но вы можете использовать файл proc.debug для его отладки в GDB.

Answer 2

Я не смог найти точного ответа на этот вопрос, но я нашел альтернативное решение, которое работает так же хорошо: скомпилируйте с оптимизацией и другими флагами выпуска вместе с -g, сохраните получившийся исполняемый файл где-нибудь, затем удалите символы отладки, используя strip. Поставьте удаленный исполняемый файл, и, когда вы получите трассировку стека, используйте addr2line в сочетании с исходным, необработанным исполняемым файлом, и вы должны вернуть все символы обратно.