arm-unknown-linux-gnueabi ABI selection

[Michael Abbott]

I'm sorry, this message has become a bit long.  So here's an attempt at an 
executive summary:

1. Sorry, my analysis was wrong, but *something's* broken with the EABI 
configuration setup!
2. I can't build a good toolchain (sizeof(enum)==1 is a disaster).
3. It's possible my second rebuild went wrong somewhere (I'm doing a third 
rebuild now).


On Fri, 29 Aug 2008, Yann E. MORIN wrote:
> On Friday 29 August 2008 09:08:13 Michael Abbott wrote:
> > I'm rebuilding now with something along these lines.  I think this 
> > code in arch/arm/functions is wrong:
...
> > 	    unset ... CT_ARCH_ABI ...
> Wrong, re-read the code again, please. The variable that gets unset is 
> CT_ARCH_WITH_ABI,

Oops.  I'm sorry, I'd completely misinterpreted the problem, and in that 
light I was looking for the wrong error.  I thought I had a fix, and was 
trying to see why the fix was needed, and I think I must have been too 
tired to be looking straight.  

Instead, my original problem remains unfixed, and my analysis of 
whatever's wrong in crosstool is completely wrong.  (Alas, my machine 
takes 80 minutes to do a build, which makes research a bit painful!)

I think that the ABI flag is inconsistent with selecting EABI and should 
simply disappear when EABI is selected ... but, see below, I don't 
understand the issue properly yet.


So let me go right back to the beginning.  


The basic problem seems to be that building
	samples/arm-unknown-linux-gnueabi
produces a toolchain which doesn't work properly (more on that in a 
moment).  Unfortunately setting CT_ARCH_API to "" or to "aapcs" doesn't 
make any difference (I've just done the appropriate tests, a little bit 
more on this at the bottom).

So what is the problem?  Very simply: it would appear that the ARM EABI 
requires that enums be 4 bytes -- apparently the compiler flag aapcs-linux 
is supposed to selected this (at least so 
	http://wiki.debian.org/ArmEabiPort#line-104
says) -- but I've not yet managed to build a toolchain which does this.

First a demonstration of the problem:

$ cd x-tools
$ cat test.c
enum test { TEST };
int size() { return sizeof(enum test); }
$ ./arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc -S 
-O2 test.c
$ cat test.s |grep -Ev $'^\t(\.|@)'
size:
	mov	r0, #1
	bx	lr
$

In other words, small enums fit into a single byte.

Why is this a problem?  I haven't managed to find a definitive reference 
for the ARM EABI (beyond the debian page linked above), but there's clear 
evidence that at least part of glibc expects enums to be at least two 
bytes -- the following edited snippet is from glibc-2.7/sunrpc/xdr.c:

xdr_enum (XDR *xdrs, enum_t *ep)
{
  enum sizecheck { SIZEVAL };
  if (sizeof (enum sizecheck) == 4)
    ...
  else if (sizeof (enum sizecheck) == sizeof (short))
    ...
  else
    return FALSE;  // <--- this is the case we get!
}

Whoops.  The consequence of this is that the RPC api fails (so rpcinfo 
fails), and in particular NFS mounts will always fail.


Martin Guy says:
> The trick is to check "EABI" and leave the ABI field blank - it
> correctly selects aapcs and aapcs-linux in the various contexts they
> are required.
 
Well, I've just tried that: I used `ct-ng menuconfig` to set the 
"Generate code form the specific ABI" option to "", and I got the same 
result:

$ diff .config samples/arm-unknown-linux-gnueabi/crosstool.config
...
< CT_ARCH_ABI=""
---
> CT_ARCH_ABI="aapcs"
$



Any ideas?  I'm stumped here!

It's odd: the internal dump of the toolchain configuration does indeed say

[DEBUG]    CT_ARCH_ABI=
[DEBUG]    CT_ARCH_ABI_CFLAGS=-mabi=aapcs-linux

but when I search rest of the log I don't see -mabi anywhere else!

$ bzcat build.log.bz2 | grep -n mabi
286:[DEBUG]    CT_ARCH_ABI_CFLAGS=-mabi=aapcs-linux
$

Hmm.

Oh, that's *very* interesting.  When I search the build log for the build 
I did earlier (with a vanilla .config, i.e. CT_ARCH_ABI="aapcs"), I find 
the flag *everywhere*:

$ bzcat build.log.bz2 | grep -n mabi | wc -l
4226
$

Well now, that's rather interesting.  I'm still stumped though.  Guess I'd 
better describe exactly what I did:

1. Extract fresh download of crosstool-ng-1.2.2
2. ./configure --local && make
3. Copy samples/arm-unknown-linux-gnueabi/crosstool.config to .config and 
run `ct-ng menuconfig` to tweak the local paths slightly (and set 
CT_PARALLEL_JOBS=2)
4. Run ct-ng build
5. Verify that sizeof(enum)==1
6. mv x-tools/arm-unknown-linux-gnueabi x-tools/arm-unknown-linux-gnueabi.aapcs

7. Run ct-ng menuconfig again to set CT_ARCH_ABI=""
8. Build and verify that sizeof(enum) is still == 1.

But why such a big difference in the log files?

One thing I haven't tried is erasing the targets directory before step (8) 
-- guess I'll try that now (and report back later if it makes a 
difference).  Certainly the second build log is half the size of the 
original...

--
For unsubscribe information see http://sourceware.org/lists.html#faq