This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |