linux - Différence entre les compilateurs arm-eabi arm-gnueabi et gnueabi-hf




gcc linux-kernel linux-device-driver (2)

Je ne suis pas complètement sûr:

  • l'eabi représente la compilation du code qui fonctionnera sur le noyau du bras nu.
  • le gnueabi représente la compilation de code pour Linux

Pour la partie gnueabi / gnueabi-hf, j'ai trouvé une réponse ici .

gcc-arm-linux-gnueabi est le paquetage cross-toolchain pour l'architecture d'armel. Cette chaîne d'outils implique l'EABI généré par les options -mfloat-abi = soft ou -mfloat-abi = softfp de gcc.

gcc-arm-linux-gnueabihf est le paquetage cross-toolchain pour l'architecture armhf. Cette chaîne d'outils implique l'EABI généré par l'option gcc -mfloat-abi = hard.

Quelle est la différence entre les compilateurs croisés arm-eabi, gnueabi et gnueabi-hf. Je trouve difficile de choisir les compilateurs. Y a-t-il un compilateur natif pour le bras?


One point no-one seems to have mentioned. You say you're developing in GCC and cross-compiling onto ARM. How do you know that you don't have code which makes assumptions about free RAM, integer size, pointer size, how long it takes to do a certain operation, how long the system will run for continuously, or various stuff like that? This is a very common problem.

The answer is usually automated unit testing. Write test harnesses which exercise the code on the development system, then run the same test harnesses on the target system. Look for differences!

Also check for errata on your embedded device. You may find there's something about "don't do this because it'll crash, so enable that compiler option and the compiler will work around it".

In short, your most likely source of crashes is bugs in your code. Until you've made pretty damn sure this isn't the case, don't worry (yet) about more esoteric failure modes.





linux gcc linux-kernel arm linux-device-driver