From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Clifton To: mega74@vitals.co.kr Cc: Binutils Subject: Re: ABI ???? Date: Thu, 23 Aug 2001 00:13:00 -0000 Message-id: References: <3B848035.DB0244DC@vitals.co.kr> X-SW-Source: 2001-08/msg00528.html Hi Myunghui, > I was checked my cross-compiler. That use a ELFOSABI_ARM options. > > But, my old-tool is not EI_OSABI option. > > Please, explain to me about OS ABI. The ELF spec defines the EI_OSABI value as follows: Byte e_ident[EI_OSABI] identifies the OS- or ABI-specific ELF extensions used by this file. Some fields in other ELF structures have flags and values that have operating system and/or ABI specific meanings; the interpretation of those fields is determined by the value of this byte. If the object file does not use any extensions, it is recommended that this byte be set to 0. If the value for this byte is 64 through 255, its meaning depends on the value of the e_machine header member. The ABI processor supplement for an architecture can define its own associated set of values for this byte in this range. If the processor supplement does not specify a set of values, one of the following values shall be used, where 0 can also be taken to mean unspecified. Name Value Meaning ELFOSABI_NONE 0 No extensions or unspecified ELFOSABI_HPUX 1 Hewlett-Packard HP-UX ELFOSABI_NETBSD 2 NetBSD ELFOSABI_LINUX 3 Linux ELFOSABI_SOLARIS 6 Sun Solaris ELFOSABI_AIX 7 AIX ELFOSABI_IRIX 8 IRIX ELFOSABI_FREEBSD 9 FreeBSD ELFOSABI_TRU64 10 Compaq TRU64 UNIX ELFOSABI_MODESTO 11 Novell Modesto ELFOSABI_OPENBSD 12 Open BSD 64-255 Architecture-specific value range The value of ELFOSABI_ARM is 97, which places it in the architecture specific range. This value is in fact specific to the binutils toolsuite, as ARM's own tools do not use it. (ARM's ELF spec does not mention the field, so it defaults to 0). Binutils uses this value to distinguish between the "old" implementation of ARM's ABI and the "new" implementation. The terms "old" and "new" here are misnomers. The "old" implementation was actually a broken implementation of the ABI and the "new" implementation was the bug-fixed version. Unfortunately these two implementations are incompatible at a binary level, hence the need of a distinct value to distinguish between the two. Cheers Nick