Почему DumpBin сообщает, что в моих двоичных файлах нет COMDAT? - PullRequest
4 голосов
/ 29 июля 2010

Это вывод, который я получаю с dumpbin AchievementsTable.obj /HEADERS

Microsoft (R) COFF/PE Dumper Version 8.00.50727.762
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file AchievementsTable.obj

File Type: ANONYMOUS OBJECT

ANON OBJECT HEADER VALUES
               1 version
             14C machine (x86)
        4C51334D time date stamp Thu Jul 29 08:52:45 2010
                 ClassID: {0CB3FE38-D9A5-4DAB-AC9B-D6B6222653C2}
            945F size
               0 flags

ВСЕ мой источник делает это.Я использую VisualStudio 2005. Я точно знаю, что экспортируется много COMDAT, так как .exe впоследствии связывается и выполняется правильно: есть ли ключи компилятора, которых мне следует избегать?Вот те, которые я использую:

/O1
/Ob2
/Oi
/GT
/GL
/I "..\dxsdk\include" <lots of include paths>
/D "WIN32" <lots of #defines>
/GF
/FD
/MT
/GS-
/Gy
/arch:SSE2
/fp:fast
/GR-
/Fo <directory specified>
/Fd <pdb filename specified>
/FR <directory specified>
/W4
/c
/Zi
/TP .\Source\databases\AchievementsTable.cpp

Я открыт для комментариев по моему выбору в целом, но использование DumpBin является предметом этого вопроса: уберите это, мальчики и девочки ...

1 Ответ

7 голосов
/ 30 июля 2010

После дня исключения я обнаружил, что документация DUMPBIN немного двусмысленна.

Включение связывания на уровне функций (/ Gy) необходимо для получения выхода COMDAT. Включение межмодульной оптимизации (/ GL) задерживает генерацию кода на время соединения. Следовательно, хотя информация заголовка доступна для кода, скомпилированного с / GL, она очень ограничена. Вот почему это единственная опция, доступная для DUMPBIN - все остальные опции требуют больше информации, генерация которой задерживается /GL.

...