embedded - none - brazo-linux-gcc vs brazo-elf-gcc
install arm none eabi gdb (6)
Estoy mirando el sistema uClinux que construye el kernel con arm-linux-xxx, pero construye las aplicaciones de usuario con arm-elf-xxx.
Si las aplicaciones están destinadas a ejecutarse en Linux, ¿no sería mejor construir todo con arm-linux-xxx?
¿Dónde se establece una opción en la configuración de compilación general de uClinux?
ELF es el formato binario de Linux y muchos otros usan:
El formato ELF ha reemplazado formatos ejecutables más antiguos como a.out y COFF en muchos sistemas operativos tipo Unix como Linux, Solaris, IRIX, FreeBSD, NetBSD, OpenBSD, DragonFly BSD, Syllable y HP-UX (excepto para 32- programas bit PA-RISC que continúan usando SOM). ELF también ha visto cierta adopción en sistemas operativos que no son Unix, como la versión Itanium de OpenVMS y BeOS Revisión 4 y posterior para equipos basados en x86 (donde reemplazó el formato Portable Executable, la versión PowerPC se quedó con Preferred Executable Format). Las consolas PlayStation Portable, PlayStation 2, PlayStation 3, Wii y GP2X también usan ELF. AmigaOS 4 y MorphOS también se ejecutan en máquinas PowerPC, usan ELF. En la plataforma Amiga, el ejecutable ELF ha reemplazado al EHF anterior (formato de formato extendido) que se utilizó en Amigas equipado con tarjetas de expansión de procesador PPC. El sistema operativo Symbian v9 usa el formato E32Image [3] que se basa en el formato de archivo ELF.
La mayoría de Sony Ericsson (por ejemplo, el W800i, W610, K790, etc.), algunos Siemens (plataformas SGOLD y SGOLD2: de Siemens C65 a S75 y BenQ-Siemens E71 / EL71) y Motorola (por ejemplo, el E398, SLVR L7) , v360, v3i y todos los teléfonos LTE2 a los que se aplica el parche), los teléfonos pueden ejecutar archivos ELF mediante el uso de un parche que agrega código de ensamblaje al firmware principal (conocido como ELFPack, en la cultura de modding subterránea).
Me parece recordar en algún momento que ese poco en el medio no importaba. Como el elf ya mencionado es el formato de archivo estándar, desea usarlo de todos modos y lo obtendrá de todos modos independientemente del nombre binario. Lo que puede ser (o no) más importante es la convención de llamadas, no sé si al llamar a una función de biblioteca compartida debe hacer que su convención de llamadas coincida o si se maneja para usted en otro lugar.
Los nombres de los compiladores no significan necesariamente nada. Dependiendo de quién creó los compiladores (y los denominó), obtendrá diferentes resultados. Podría decirse que hay un nombre correcto para una configuración en particular, pero algunos gcc compilados aleatoriamente pueden no ser correctos.
Para los compiladores de CodeSourcery (probablemente los nombres más correctos), consulte la página de sus plataformas para conocer su significado.
La diferencia es que la salida vinculada de la cadena de herramientas arm-elf-xxx es un binario cargable de linux, mientras que arm-linux-xxx genera un objeto kernel (ko), que es un blob con su propio formato de vinculación (para módulos), o el kernel principal en sí mismo, que no necesita un formato de empaque. Es decir, para el espacio de usuario, desea que el objeto final vinculado dinámicamente sea un ejecutable ELF, una biblioteca o un objeto compartido. Para el espacio del kernel, desea que el objeto final (kernel o módulo) esté en el formato de vinculación linux-arm-kernel.
Notarás que los objetos intermedios (archivos .o) de ambos objetivos son probablemente todos ELF, ya que eso es lo que espera la cadena de herramientas.
Puede ejecutar arm-linux-gcc -v y arm-elf-gcc -v para ver algunas diferencias entre estas dos versiones de gcc (como las arquitecturas / idiomas de destino).
En nuestro caso construimos Linux usando sparc-elf-gcc y construimos busybox (aplicación ejecutándose en linux) usando sparc -... linux-gcc. y creo que esto es correcto, no al revés.