ls returns large file sizes

[Jonathan Lester]

It looks like the toolchain I made has broken large file support
somehow. If I compile a test application with stat and stat64 with it I
get 17592186044416 from stat64. If I compile it with the other toolchain
I get the correct result. 

Interestingly if I compile Busybox without large file system support I
this on boot:
/etc/init.d/rcS: /etc/init.d/rcS: 11: hostname: Value too large for
defined data type
*** glibc detected *** double free or corruption (fasttop): 0x00127478
***
Aborted

[I don't know what the double free is from]
Along with some more errors and I'm unable to login. The line its trying
to parse in /etc/init.d/rcS is:
  hostname -F /etc/HOSTNAME

This probably is another symptom of something in the toolchain being
broken... So it looks like I need to figure out how to either fix the
toolchain crosstool is building or use the other toolchain (from
arm.linux.org). 

Btw, the original reason for building our own toolchain was that when we
upgraded to the 2.6.14 kernel we couldn't run any older binaries on our
target platform without getting an 'Illegal instruction' when control
was handed over from libc to the program. We found that you could do
/lib/ld-linux.so.2 <myApp> and it worked fine but I was hoping a new
toolchain could somehow fix this (and of course it didn't). I'll ask on
the arm-linux list to see if anyone knows what this is but if anyone
here knows what would cause this I'd love to be able to fix this (I
tried all sorts of abi/oldest glibc flags with no luck). 

Cheers
-Jonathan 


-----Original Message-----
From: Rob Landley [mailto:rob at landley.net] 
Sent: Wednesday, December 21, 2005 9:50 PM
To: busybox at busybox.net
Cc: Mike Frysinger; Jonathan Lester
Subject: Re: ls returns large file sizes

On Wednesday 21 December 2005 23:02, Mike Frysinger wrote:
> > [arm-readelf also says all the data sections are little endian]
> > Is there any good way to test how the kernel and the library return
the
> > 'stat' structure to see if someone thinks they're supposed to use
big
> > endian?
>
> i asked about big endian because there was a bug (maybe still is,
> havent check glibc) in the stat struct for big endian targets
>
> you could should compile a small .c file which calls the kernel
> stat functions itself rather than using the libc stat functions
>
> that'd tell you if the kernel was sane or not
> -mike

It's either an endianness issue or a 32/64 bit confusion issue
(compiling for 
large file support and your kernel having no idea what that is,
perhaps)?  I 
don't know specifically about arm but a 2^44 value for a file size
sounds to 
me like "grabbing 64 bits of data from a 32 bit field".  Wild guess.  Of

course if there's a known endianness issue on arm, that would be the
first 
thing to check.  (Do the headers you compiled against bear any relation
to 
the kernel you're actually running this stuff on?)

Obviously, this is an area that worked for us when we tried it, which
means 
something in your build or runtime environment differs from what we
have...

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.