Параметр g++ -g эквивалентен компилятору VS2010 cl?

С g++ с опцией -g, я могу использовать gdb для целей отладки.

Что эквивалентно этому параметру с компилятором Visual Studio 2010 cl.exe?

Эта страница содержит разные библиотеки (debug/ релиз) для ссылки.

Если я компилирую с параметром отладки с помощью cl.exe, нужно ли мне использовать соответствующие параметры связывания библиотек (/MD/MT или /MDd/MTd)?


person prosseek    schedule 11.01.2011    source источник


Ответы (2)


В этом вопросе есть несколько отдельных частей: как указать компилятору/компоновщику генерировать и сохранять «отладочную информацию» (сопоставление исходного кода и объектного кода), как указать компилятору компилировать код по-другому, чтобы упростить отладку ( подумайте об assert() и #ifdef _DEBUG), а также о том, содержат ли предварительно скомпилированные библиотеки, которые вы подключаете к своему проекту, отладочную информацию.

-Zi (флаг для компилятора CL, чтобы указать ему генерировать отладочную информацию) является эквивалентом флага -g gcc.

(Существуют и другие формы параметра -Z: -ZI, если вам нужна поддержка «редактировать и продолжить» в Visual Studio IDE, но если вы используете IDE, вы, вероятно, используете его интерфейс для настроек компилятора вместо манипулируя ими напрямую, и -Z7, если вам нужна отладочная информация старого формата CodeView; всякий раз, когда я вызывал CL напрямую, я всегда хотел -Zi.)

Обратите внимание, что при использовании параметра -Zi (или -ZI) обычно создается файл .pdb для каждого каталога, но когда вы связываете код вместе, он может быть получен из файлов .obj, представленных в разных файлах .pdb, и вы также хотите объедините эти отдельные файлы .pdb в главный, представляющий код, который вы скомпоновали вместе - для этого предназначен переключатель -debug для компоновщика.

Также обратите внимание: это может показаться нелогичным, но всегда используйте -Zi (для CL) и -debug (для link.exe). Даже для кода, который вы собираетесь выпустить. Это не увеличивает размер вашего исполняемого файла и не раскрывает секреты вашим клиентам, поскольку отладочная информация хранится в отдельном файле .pdb (который вы не отправляете клиентам). Если есть шанс, что вам когда-нибудь придется его отлаживать, вам понадобится .pdb. (-Zi даже не является несовместимым с оптимизацией, хотя -ZI. Так что вы можете захотеть скомпилировать свои "отладочные" сборки с -ZI, а ваши "выпускные" сборки с "-Zi -O2".)

Что касается библиотек: вам не обязательно сопоставлять свойство отладки/выпуска библиотеки времени выполнения C с тем, включает ли ваш код отладочную информацию, но обычно это хорошая идея - если вы собираетесь отлаживать проект, который хотите чтобы иметь возможность отлаживать все это, и если вы не собираетесь отлаживать, вам не нужен лишний вес. Использование отладочных/релизных версий данной библиотеки не повлияет на наличие в ней символов отладки (надеюсь, если тот, кто компилировал библиотеку, понял, что я сказал в предыдущем абзаце), но повлияет на такие вещи, как утверждение и дополнительные #ifdef _DEBUG. код в этой библиотеке.

Это относится ко всем библиотекам, с которыми вы связываетесь, но особенно к библиотеке времени выполнения C — Microsoft добавила дополнительный код обнаружения ошибок в malloc() и free(). Так что, если что-то в вашем проекте использует отладочный вариант библиотеки CRT, все это должно быть так.

Параметры /M (/MTd и /MDd), на мой взгляд, странные и волшебные — они просто псевдонимы для сложного набора других вещей, происходящих за кулисами. Возьмем, к примеру, /MDd, задокументированный как «Определяет _DEBUG, _MT и _DLL и заставляет ваше приложение использовать отладочную многопоточную и специфичную для DLL версию библиотеки времени выполнения. Это также заставляет компилятор размещать имя библиотеки MSVCRTD. lib в файл .obj». Здесь это влияет как на препроцессор (определяющий _DEBUG и некоторые другие символы препроцессора), так и на компоновщик (фактически он помещает комментарий #pragma (линкер) в ваш исходный код). Если вам небезразлично, что происходит, но вы этого не понимаете, это может вызвать настоящие проблемы — я видел множество проектов, не использующих IDE, увязших в предупреждениях как о msvcrt.lib, так и о msvcrtd.lib. быть подключенным и т. д. К тому времени, когда вы поймете, как безопасно использовать эти (параметры /M), они вам больше не понадобятся! Я предпочитаю делать вещи явными: указывать «-D _DEBUG» непосредственно там, где мне это нужно, явно указывать, с какими библиотеками связываться (и использовать -nodefaultlib), а затем параметры /M не нужны.

person metamatt    schedule 11.01.2011
comment
+1 Вау. Могу я спросить, как вы так хорошо познакомились с особенностями цепочки инструментов Microsoft? :) - person Frédéric Hamidi; 12.01.2011
comment
Годы и годы использования разных версий MSVC, множество кроссплатформенных проектов, поэтому мы использовали make-файлы или иным образом обходили систему сборки IDE, используя библиотеки с открытым исходным кодом, созданные сторонними разработчиками, поддерживая все это в рабочем состоянии при обновлении до новых версий MSVC или SDK и т. д. :) - person metamatt; 12.01.2011

Вам нужен один из созданий отладочной информации. параметры (/Z7, /Zi или /ZI).

Если вы используете один из них, вы также должны передать /DEBUG компоновщику.

Вам также потребуется создать ссылку на отладочную версию библиотек времени выполнения (/MDd или /MTd). Это важно, потому что эти версии отличаются от своих выпускных аналогов (например, их подпрограммы выделения памяти несовместимы).

person Frédéric Hamidi    schedule 11.01.2011