Comment définir un point d’entrée C personnalisé avec Clang sur OS X Mavericks?

J’ai le programme suivant:

#include  int bob() { printf("bob\n"); return 0; } int main() { printf("main\n"); return 0; } 

Sous Linux, je peux activer un point d’entrée personnalisé via:

 gcc test.c -Wl,-e,bob 

Lorsque je lance le programme résultant, je reçois:

 ./a.out bob 

Sous OS X, toutefois, cela ne fonctionne pas:

 clang test.c -Wl,-e,bob ./a.out main 

J’ai tout essayé pour que cela fonctionne. Je pense que cela pourrait être un bug. Voici la sortie avec l’option -v :

 clang test.c -Wl,-e,bob -v Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.3.0 Thread model: posix "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -sortingple x86_64-apple-macosx10.9.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name test.c -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 236.3 -v -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.1 -fdebug-compilation-dir /Users/mfichman/jogo -ferror-limit 19 -fmessage-length 125 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.9.0 -fencode-extended-block-signature -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -o /var/folders/4z/q41by0256hjc7s6v8ljmfpw8lywh5g/T/test-9b80a6.o -xc test.c clang -cc1 version 5.1 based upon LLVM 3.4svn default target x86_64-apple-darwin13.3.0 #include "..." search starts here: #include  search starts here: /usr/local/include /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.1/include /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.9.0 -e bob -o a.out /var/folders/4z/q41by0256hjc7s6v8ljmfpw8lywh5g/T/test-9b80a6.o -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.1/lib/darwin/libclang_rt.osx.a 

Vous pouvez voir que clang passe correctement -e à ld , alors c’est peut-être un problème avec le ld d’Apple. Si tel est le cas, je serais intéressé par des solutions de rechange.

    Le point d’entrée par défaut remplacé par l’argument -e n’est pas _main mais start , responsable de la configuration et de l’appel de _main , puis de la valeur _main de _main à _exit . Si vous spécifiez votre propre point d’entrée, vous devrez suivre ces étapes vous-même. Il n’y a actuellement aucun moyen de faire cette initialisation pour vous mais utilisez une fonction principale différente car l’utilisation de _main est codée en dur dans les outils.

    La raison pour laquelle votre argument -e est ignoré est due à une modification de 10.8. Avant cette version, la mise en œuvre de start était liée à chaque application via crt1.o Dans la section 10.8, le traitement de start peut être effectué par dyld et la commande de chargement LC_MAIN spécifie le décalage par rapport à la fonction principale du programme. Changer ce décalage semble être ce que vous voulez, mais ce n’est pas possible actuellement car lorsque la méthode de démarrage LC_MAIN est utilisée, ld utilise toujours _main et ignore l’argument -e . Pour spécifier votre propre point d’entrée, vous devez indiquer à ld d’utiliser l’ancienne méthode de démarrage du programme, ce que vous pouvez faire pour une application avec une cible de déploiement -no_new_main ou supérieure à 10.8 en transmettant -no_new_main à l’éditeur de liens. Il s’agit du comportement par défaut pour les applications avec une cible de déploiement antérieure à 10.8.