문제란 바라는 것과 인식의 차이이다

• http://wiki.debian.org/ArmEabiPort

일단..
EABI라는 것은 ARM社에서 만들어낸 "Embedded" ABI라고 합니다.
여기서 ABI는 Application Binary Interface의 약자로

• http://www.codesourcery.com/gnu_toolchains/arm/faq.html

위 link에 가보면, 자세한 설명이 나와 있습니다.  글을 읽다가 www.arm.com으로 연결되는 link를 눌렀더니 대략 12개의 문서 link가 나타나는 군요.. 그 녀석들을 읽는 것은 일.단. 보류 입니다. -_-;;

• http://www.arm.com/products/DevTools/ABI.html

에 가보면 첫 머리에 다음과 같은 문장이 있습니다.
The Application Binary Interface (ABI) for the ARM^® Architecture is a collection of standards, some open and some specific to the ARM architecture. The standards regulate the inter-operation of binary code, development tools, and a spectrum of ARM core-based execution environments from bare metal to platform operating systems such as ARM Linux.

Version 1.0 of the base standard was principally concerned with governing inter-operation between relocatable files. This release - version 2.0 - also sets standards for executable files.

결국은.. Binary code가 "어떻게" 실행될 것이냐에 대한 표준을 정의한 문서들이라고 보여집니다.. 흠..

다시 debian wiki로 돌아와 보면, EABI는 다음과 같은 변화가 있다는데요..

• Mixing soft and hardfloat code is possible
• Structure packing is not as painful as it used to be
• More compatibility with various tools (in future - currently linux-elf is well supported)
• A more efficient syscall convention
• At present (with gcc-4.1.1) it works with ARMv4t, ARMv5t processors and above, but supporting ARMv4 (e.g., StrongARM) requires modification to GCC.

딱히 와닿는 변화는 없어 보입니다.  아무래도 compiler의 성능향상에는 좀 영향을 주겠네요.

이 새로운 ABI는 새로운 ABI field를 가지는 것 뿐 아니라, 새로운 GCC target을 생성합니다.  이게 문제죠..-_-

Legacy ABI

• ABI flags passed to binutils: -mabi=apcs-gnu -mfpu=fpa
• gcc -dumpmachine: arm-unknown-linux
• objdump -x for compiled binary:
  private flags = 2: [APCS-32] [FPA float format] [has entry point]
• "file" on compiled Debian binary
  ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), for GNU/Linux 2.2.0, stripped

ARM EABI

• ABI flags passed by gcc to binutils: -mabi=aapcs-linux -mfloat-abi=soft -meabi=4
• gcc -dumpmachine: arm-unknown-linux-gnueabi
• objdump -x for compiled binary:
  private flags = 4000002: [Version4 EABI] [has entry point]
• "file" on compiled binary (under Debian)
  ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.4.17, dymically linked(uses shared libs), for GNU/Linux 2.4.17, stripped

문제가 되는 부분이 빨간색 글씨로 표시되어 있습니다.  결국 GLIBC를 upgrade해야 문제가 해결될 듯한 안좋은 조짐이 보이기 시작합니다.. -_-;;  물론 앞에서 언급한 http://codesourcery.com/gnu_toolchains/arm/faq.html에 가면, codesourcery.com에서 배포해주는 GLIBC를 download할 수 있습니다. 

1. How do I install CodeSourcery's version of GLIBC on my target system?

1. I've installed CodeSourcery's GLIBC. How do I use it?

설치하는 법도 자세히 나와있습니다.  하지만, source를 사용해서 build하는 법을 알아야 사후 bug발생시 해결할 수 있기 때문에 쫌 찜찜하네요.. -_- 이런 질문이 있습니다.

EABI와 non-EABI binary를 하나의 system에서 동시에 쓸 수 있냐는 질문도 있네요..
여기에 대해서는 가능하지만 주의가 필요하다 합니다.  만약 Legacy ABI system에서 EABI를 실행하길 원한다면, --static option으로 program을 static link로 쓰거나 LD_LIBRARY_PATH를 서로 다르게 두면 된다고 합니다.. 요거 미봉책같은 느낌이네요.. -_-

결국 EABI로 upgrade는 불가피해 보입니다.  지금이야 아직 gcc 4.x를 잘 안쓰지만, 시간이 지나면 linux kernel도 gcc4.x로 build해야 할 때가 올 것이고, 그렇게 된다면 기존 ABI를 쓰던 cross compile 환경을 바꿔야만 하게 될 것 같습니다.  지금은 결과를 내야 해서 Legacy ABI로 가지만, 슬슬 EABI를 사용할 수 있는 root filesystem과 library를 준비해야 겠습니다.. 결론!