Andrew Dyer wrote on Wednesday, March 10, 2010 4:50 PM: > On Wed, Mar 10, 2010 at 5:09 AM, Martin Krause <martin.kra...@tqs.de> > wrote: >> Hi Praveen, >> >> u-boot-boun...@lists.denx.de wrote on Tuesday, March 09, 2010 8:35 >> PM: >>> Hello, >>> >>> I am using the ARM11 platform, and I notice that when I build the >>> uboot code, the -mabi option is set to aapcs-linux and >>> thumb-network. With this change, I have problems in getting the >>> ext2ls function to work. I was able to narrow down the problem, >>> and in the ext2fs_iterate_dir function, I see this statement >>> >>> char filename[dirent.namelen + 1]; >>> >>> status = ext2fs_read_file (diro, >>> fpos + sizeof >>> (struct ext2_dirent), >>> dirent.namelen, filename); >>> >>> I then call the ext2fs_read_file, but when I return back the Program >>> counter is all messed up and it doesn;t follow the next statement. >>> >>> I replaced the character filename declaration with malloc, and >>> ext2ls worked well. I want to know whether this is a known bug? >> >> I can confirm this behavior. I run a test on a S3C6410 ARM11 board. >> With the original code, U-Boot dies during a "ext2ls", with the >> modification with malloc() it works. >> >> I think the reason for the failure ist the definition of "filename". >> "filename" is defined as variable lenght array. The length of the >> array is calculated during run time. Since the variable is stored >> on the stack, I assume that there is an error in the length >> calculation and something on the stack is overwritten. >> >> If "filename" is defined as fixed length array (I tested with >> char filename[2048]) everything works OK. >> >> For me this looks like a compiler or toolchain problem which >> leaves me in a somewhat uncomfortable feeling ... > > this is a total guess, but might this have something to do with the > relocation? A malloc will allocate off the heap at run time, perhaps > the compiler or linker is generating code that assumes something about > memory layout that isn't true.
Hm, on the wikipedia article for the 'variable length arrays' (VLA) I read, that the GNU C compiler always uses the stack for this type of variables. So I think, if the stack is working for all other local variables, it should not be an memory layout problem. Eventually the following might be interesting. I have tried to make the VLA much bigger, to eliminate 'normal' buffer overrun problems: char filename[dirent.namelen + 1 + 2048] But this leads to the same result, U-Boot dies. With an fixed length array of comparable length it works: char filename[2048] Both (local) variables should end up on the stack. Regards, Martin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot