2010-04-12 17:56:39 64bit compiler woes?
Ian Jeffray (UNITED KINGDOM)
Message: 88342
I believe I'm seeing a problem that's related to the 64bit toolchain, as doubtful as that may seem.
I'm building the trunk blackfin kernel with the latest release toolchain 2009r1.1-2 (gcc version 4.1.2 (ADI svn)) on a 64bit Ubuntu server - vfat is going bananas.
Build the same source on the same machine but with a 32bit debian OS, and things are perfectly fine.
What's happening is that the entries on my mmc_spi SD card (various BF5xx targets) are "mixed up" - the filenames appear to be sane, but the fat entries they point to are wrong - the file sizes match the data they're pointing at but are not the correct entries for the filename. Many filenames are pointing to the same data too... it's really very weird indeed!
I've verified various SD cards on various other machines, formatted them in both Windows and Linux, all sorts of combinations, and it's only this build with 64bit tools that's causing the problem.
Has anyone ever seen anything this bizarre before? It's completely repeatable here on a completely unmodified git checkout of uclinux and the kernel trees, so I'd like to believe it's not something I'm managing to screw up.
Is this version of the toolchain actually sane/suitable for building the latest kernel? Everything else seems fine, except for this vfat nonsense.
QuoteReplyEditDelete
2010-04-12 18:21:22 Re: 64bit compiler woes?
Mike Frysinger (UNITED STATES)
Message: 88343
you're not the first to report this (vfat weirdness w/64bit toolchain), but we havent been able to reproduce this behavior. using the 32bit toolchain on a 64bit host should work fine too.
if you build just the kernel with a different toolchain, do things work ? or do you have to build both with the 64bit toolchain to have things fail ?
QuoteReplyEditDelete
2010-04-12 19:54:48 Re: 64bit compiler woes?
Ian Jeffray (UNITED KINGDOM)
Message: 88344
Yes, just using a 32bit toolchain for the kernel alone resolves this.
Digging a little deeper, the differences start to creep in in fs/fat/dir.c around __fat_readdir() The register usage in this file is changes between compilers but also the instruction scheduling starts changing quite a lot in __fat_readdir() ... to the point where I can't really tell if the code is even logically the same. There's more instructions in the output of the 32bit compiler, at least. Possibly the worst after around line 563 ... if (sbi->options.dotsOK) {
I could be barking up the wrong tree here of course - it's really tricky to compare output when the scheduling's very different, but it's surprisingly precisely identical for other files, suggesting something really is afoot in dir.c.
QuoteReplyEditDelete
2010-04-12 20:04:05 Re: 64bit compiler woes?
Mike Frysinger (UNITED STATES)
Message: 88345
could you post the two linux binaries please as well as your kernel config ?
and run `make fs/fat/dir.s` and post the dir.s file as an attachment (between the two toolchains).
QuoteReplyEditDelete
2010-04-12 20:50:57 Re: 64bit compiler woes?
Ian Jeffray (UNITED KINGDOM)
Message: 88346
You want the whole vmimages? Here we go. The config is prettymuch standard - just moved things to builtins rather than modules and enabled msdofs,vfat, some NLS stuff etc. I've not actually got around to testing VFAT on other devices but have no reason to believe it's an SD/MMC specific problem.
vmImage.gz.32bit
dir.s.32bit
dotconfig
vmImage.gz.64bit
dir.s.64bit
QuoteReplyEditDelete
2010-04-14 00:34:24 Re: 64bit compiler woes?
Mike Frysinger (UNITED STATES)
Message: 88397
thanks, with your dotconfig, i can reproduce the dir.s difference on my system. i'll open a tracker item on the issue.