La version de débogage de Clang construit avec MinGW sur Windows 10 ne peut pas être exécutée

Question

J'ai construit Clang avec MinGW sur Windows avec le triple x86_64-w64-windows-gnu cible. Les exécutables clang.exe et clang ++. Exe fonctionnent comme prévu si je les construis en mode release (ils compilent des programmes sans erreur), mais en mode debug, je ne peux pas les exécuter et obtenir this error - "Cette application ne peut pas fonctionner sur votre PC ". Les autres exécutables de la même version, tels que clang-check.exe, n'affichent pas cette erreur et s'exécutent correctement. Il semble que cela puisse être un problème avec la taille du fichier, car clang.exe et clang ++ .exe font tous deux plus de 2 Go alors que les autres exécutables sont plus petits mais j'avais l'impression que la taille de fichier était limitée à 64 Go. Windows-bit est de 4 Go.

Est-ce que quelqu'un d'autre a rencontré un problème similaire? Si la taille du fichier est le problème, est-il possible d'obtenir LLVM pour mettre les symboles de débogage dans un fichier séparé pour réduire la taille de l'exécutable?

EDIT: J'ai essayé de réduire la taille de l'exécutable en vidant les symboles de débogage dans un fichier séparé en utilisant l'indicateur -gsplit-dwarf lors de la construction de LLVM mais cela n'a aucun effet.

Answer 1

Oui, la taille du fichier est un bon indice de ce problème. Le IMAGE_OPTIONAL_HEADER64.SizeOfImage field est un DWORD, suggérant une taille maximale de 4 Go. Mais il y a une autre limite qui commence en premier, le chargeur de système d'exploitation mappe l'ensemble du fichier .exe ou .dll en mémoire avec un fichier mappé en mémoire. La vue sur le fichier MMF ne peut jamais être supérieure à 2 Go. C'est une limitation technique difficile, elle s'applique même à x64. Plus d'informations sur ce problème dans this post.

Les informations de débogage sont sans aucun doute la raison pour laquelle le fichier d'image explose si mal. A titre de comparaison, la construction clang incluse avec VS2017 nécessite 27 Mo pour le frontal et 32 ​​Mo pour le backend x64. Pourquoi -gsplit-nain ne peut pas résoudre votre problème est visible depuis this project page:

Fission est mis en œuvre dans GCC 4.7, et nécessite le soutien des versions récentes de objcopy et l'éditeur de liens d'or.

MinGW ne peut pas vous fournir le lien d'or. Ils n'ont fait aucune tentative de portage car ils ne peuvent générer que des images ELF. Des faits durs et froids, tant que vous dépendez de MinGW, alors vous êtes dans une crique sans une bonne pagaie.

Quelque chose de radical est nécessaire. Je vais hésiter à mentionner Cygwin. Considérons un autre compilateur, comme utiliser Clang pour construire Clang :) ou MSVC++. L'édition de la communauté est un téléchargement gratuit. Assurez-vous également de jeter un oeil à la Clang port, ils ont fait beaucoup de travail pour le rendre compatible ABI.