[U-Boot] EABI 4.2

[Martin Krause]

Andrew Dyer wrote on Wednesday, March 10, 2010 4:50 PM:
> On Wed, Mar 10, 2010 at 5:09 AM, Martin Krause <Martin.Krause at tqs.de>
> wrote: 
>> Hi Praveen,
>> 
>> u-boot-bounces at 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