[U-Boot] EABI 4.2

[Martin Krause]

Hi Praveen,

Praveen G K wrote on Wednesday, March 10, 2010 3:45 PM:
> On Wed, Mar 10, 2010 at 5:09 AM, Martin Krause <Martin.Krause at tqs.de>
>>>  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 ...
> 
> So, what is the solution to get this problem fixed? Is the filename to
> be replaced
> with a fixed length array?

The solution would be to find the real reason and to fix it.
I spend some time exploring the assembler code generated for both
variants (with fixed length array and variable length array). But
it turned out, that my ARM assembler knowledge is to bad to find 
the place where it goes wrong in an acceptable amount of time. So
I don't know what exactly is the problem, nor I have a solution.

As workaround I generated a patch wich uses your approach with 
malloc() instead of using the variable length array. This is not 
the correct fix of the problem, but it works, and I can live with 
that for now.

Regards,
Martin