[U-Boot] Fwd: EABI 4.2

[U-Boot] Fwd: EABI 4.2

[Praveen G K]

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 didn;t see this issue on the omap3 platform (and on checking up, the
compiler flag was set to apcs-gnu and thumb-network)

Thanks,
Praveen

[U-Boot] EABI 4.2

[Praveen G K]

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 didn;t see this issue on the omap3 platform (and on checking up, the
compiler flag was set to apcs-gnu and thumb-network)

Thanks,
Praveen

[U-Boot] EABI 4.2

[Martin Krause]

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 ...

Regards,
Martin

[U-Boot] EABI 4.2

[Praveen G K]

On Wed, Mar 10, 2010 at 5:09 AM, Martin Krause <Martin.Krause@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 ...

So, what is the solution to get this problem fixed? Is the filename to
be replaced
with a fixed length array?
> Regards,
> Martin
>

[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@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

[U-Boot] EABI 4.2

[Detlev Zundel]

Hi Martin,

> 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.

Did you try to report the issue on the GCC mailing list?  A short
self-contained reproducible test case would surely help for that, maybe
you have such a thing already?

Cheers
  Detlev

-- 
Woman who seek to be equal with men lack ambition
                       -- Timothy Leary
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] EABI 4.2

[Martin Krause]

Hi Detlev,

Detlev Zundel wrote on Wednesday, March 10, 2010 4:44 PM:
> Hi Martin,
> 
>> 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.
> 
> Did you try to report the issue on the GCC mailing list?  A short

No.

> self-contained reproducible test case would surely help for that,
> maybe you have such a thing already?

Unfortunately I have no such simple test case. And since I did
not use the ext2ls command in my project at all, I'm not sure,
if I can put additional efforts in further investigations :(.

Regards,
Martin

[U-Boot] EABI 4.2

[Wolfgang Denk]

Dear Praveen G K,

In message <fe7c83ac1003100644s5603e196i5d00066abe5d88ca@mail.gmail.com> you wrote:
>
> So, what is the solution to get this problem fixed? Is the filename to
> be replaced
> with a fixed length array?

The suggested changes are not a solution, they might be used as a
workaround at best.

If a tool is broken, you go and fix the tool, not the symptoms of the
breakage.

Papering over existing bugs does not help anything.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Panic, n.: The second time you can't do it the first time.

[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@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

[U-Boot] EABI 4.2

[Joakim Tjernlund]

>
> Andrew Dyer wrote on Wednesday, March 10, 2010 4:50 PM:
[SNIP]
>
> 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.

Try alloca to see if stack allocs works at all in your toolchain.

      Jocke

[U-Boot] EABI 4.2

[Martin Krause]

Hi Jocke,

Joakim Tjernlund wrote on Wednesday, March 10, 2010 5:36 PM:
>> Andrew Dyer wrote on Wednesday, March 10, 2010 4:50 PM: [SNIP]
>> 
>> 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.
> 
> Try alloca to see if stack allocs works at all in your toolchain.

I didn't find alloca(), so I tried it with __builtin_alloca().
The result is the same as with variable length array - u-boot
dies during the ext2ls command call.

Does this mean, my toolchain is broken? I use ELDK4.2 for ARM.

Regards,
Martin

[U-Boot] EABI 4.2

[Joakim Tjernlund]

"Martin Krause" <Martin.Krause@tqs.de> wrote on 2010/03/10 17:52:40:
>
> Hi Jocke,
>
> Joakim Tjernlund wrote on Wednesday, March 10, 2010 5:36 PM:
> >> Andrew Dyer wrote on Wednesday, March 10, 2010 4:50 PM: [SNIP]
> >>
> >> 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.
> >
> > Try alloca to see if stack allocs works at all in your toolchain.
>
> I didn't find alloca(), so I tried it with __builtin_alloca().

Did you do #include <alloca.h> ?

__builtin_alloca should work too.

> The result is the same as with variable length array - u-boot
> dies during the ext2ls command call.
>
> Does this mean, my toolchain is broken? I use ELDK4.2 for ARM.

I belive so, how many bytes is in dirent.namelen? alloca can not handle to big
allocs (arch dependant) and will silently fail is it is too big.

VLA might be impl. using alloca so if alloca is broken, probably VLA too.

    Jocke

[U-Boot] EABI 4.2

[Martin Krause]

Joakim Tjernlund wrote on Wednesday, March 10, 2010 6:29 PM:
> "Martin Krause" <Martin.Krause@tqs.de> wrote on 2010/03/10 17:52:40:
>> 
>> Hi Jocke,
>> 
>> Joakim Tjernlund wrote on Wednesday, March 10, 2010 5:36 PM:
>>>> Andrew Dyer wrote on Wednesday, March 10, 2010 4:50 PM: [SNIP]
>>>> 
>>>> 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.
>>> 
>>> Try alloca to see if stack allocs works at all in your toolchain.
>> 
>> I didn't find alloca(), so I tried it with __builtin_alloca().
> 
> Did you do #include <alloca.h> ?

Yes, but then I get an "ext2fs.c:31:20: error: alloca.h: No such file 
or directory" error. I'm using an older Version of U-Boot, though ...
(U-Boot 1.3.4).

> __builtin_alloca should work too.
> 
>> The result is the same as with variable length array - u-boot
>> dies during the ext2ls command call.
>> 
>> Does this mean, my toolchain is broken? I use ELDK4.2 for ARM.
> 
> I belive so, how many bytes is in dirent.namelen? alloca can not

In the first call 2 bytes, in the second call 3 bytes, and then
U-Boot dies.

> handle to big allocs (arch dependant) and will silently fail is it is
> too big. 
> 
> VLA might be impl. using alloca so if alloca is broken, probably VLA
> too. 

This sounds plausible.

I compiled the original code with VLA with ELDK4.1 and there 
everything works. And also the '__builtin_alloca' Version works
with ELDK4.1.

Regards,
Martin

[U-Boot] EABI 4.2

[Praveen G K]

On Thu, Mar 11, 2010 at 4:11 AM, Martin Krause <Martin.Krause@tqs.de> wrote:
> Joakim Tjernlund wrote on Wednesday, March 10, 2010 6:29 PM:
>> "Martin Krause" <Martin.Krause@tqs.de> wrote on 2010/03/10 17:52:40:
>>>
>>> Hi Jocke,
>>>
>>> Joakim Tjernlund wrote on Wednesday, March 10, 2010 5:36 PM:
>>>>> Andrew Dyer wrote on Wednesday, March 10, 2010 4:50 PM: [SNIP]
>>>>>
>>>>> 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.
>>>>
>>>> Try alloca to see if stack allocs works at all in your toolchain.
>>>
>>> I didn't find alloca(), so I tried it with __builtin_alloca().
>>
>> Did you do #include <alloca.h> ?
>
> Yes, but then I get an "ext2fs.c:31:20: error: alloca.h: No such file
> or directory" error. I'm using an older Version of U-Boot, though ...
> (U-Boot 1.3.4).
>
>> __builtin_alloca should work too.
>>
>>> The result is the same as with variable length array - u-boot
>>> dies during the ext2ls command call.
>>>
>>> Does this mean, my toolchain is broken? I use ELDK4.2 for ARM.
>>
>> I belive so, how many bytes is in dirent.namelen? alloca can not
>
> In the first call 2 bytes, in the second call 3 bytes, and then
> U-Boot dies.
So, should I send a message to the gcc mailing list explaining the issue?
>> handle to big allocs (arch dependant) and will silently fail is it is
>> too big.
>>
>> VLA might be impl. using alloca so if alloca is broken, probably VLA
>> too.
>
> This sounds plausible.
>
> I compiled the original code with VLA with ELDK4.1 and there
> everything works. And also the '__builtin_alloca' Version works
> with ELDK4.1.
>
> Regards,
> Martin
>
>

[U-Boot] EABI 4.2

[Detlev Zundel]

Hi Praveen,

> So, should I send a message to the gcc mailing list explaining the issue?

Yes please.

Thanks!
  Detlev

-- 
#define KSAMTIB_CIGAM_2SFFJ 0x8519 /* For detecting wrong-endian fs */
                              -- include/linux/jffs2.h
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] EABI 4.2

[Praveen G K]

On Fri, Mar 12, 2010 at 3:04 AM, Detlev Zundel <dzu@denx.de> wrote:
> Hi Praveen,
>
>> So, should I send a message to the gcc mailing list explaining the issue?
>
> Yes please.
>
> Thanks!
> ?Detlev
OK Have sent a message to the gcc-bugs mailing list.  I hope this is
the right one.
http://gcc.gnu.org/ml/gcc-bugs/2010-03/msg01155.html
> --
> #define KSAMTIB_CIGAM_2SFFJ 0x8519 /* For detecting wrong-endian fs */
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-- include/linux/jffs2.h
> --
> DENX Software Engineering GmbH, ? ? ?MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, ?Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
>

[U-Boot] EABI 4.2

[Praveen G K]

On Fri, Mar 12, 2010 at 11:12 AM, Praveen G K <praveen.gk@gmail.com> wrote:
> On Fri, Mar 12, 2010 at 3:04 AM, Detlev Zundel <dzu@denx.de> wrote:
>> Hi Praveen,
>>
>>> So, should I send a message to the gcc mailing list explaining the issue?
>>
>> Yes please.
>>
>> Thanks!
>> ?Detlev
> OK Have sent a message to the gcc-bugs mailing list. ?I hope this is
> the right one.
> http://gcc.gnu.org/ml/gcc-bugs/2010-03/msg01155.html
I have not received any updates from the gcc mailing list.  Has anyone
got any more ideas on this? Thanks!

>> #define KSAMTIB_CIGAM_2SFFJ 0x8519 /* For detecting wrong-endian fs */
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-- include/linux/jffs2.h
>> --
>> DENX Software Engineering GmbH, ? ? ?MD: Wolfgang Denk & Detlev Zundel
>> HRB 165235 Munich, ?Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>> Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
>>
>

[U-Boot] EABI 4.2

[Alessandro Rubini]

Hello.

> I have not received any updates from the gcc mailing list.  Has anyone
> got any more ideas on this? Thanks!

Out of curiosity, I tried to reproduce the problem. I added EXT2 to my
binary and recompiled with eldk-4.2. As a reminder, this is the
source:

    if (dirent.namelen != 0) {
            char filename[dirent.namelen + 1];
            ext2fs_node_t fdiro;
            int type = FILETYPE_UNKNOWN;

            status = ext2fs_read_file (diro,
                                       fpos + sizeof (struct ext2_dirent),
                                       dirent.namelen, filename);

Note that namelen is a uint8_t. What follows is the disassembled u-boot.
My comments follow each groups of lines.

   a182025c:       e55b2026        ldrb    r2, [fp, #-38]
   a1820260:       e3520000        cmp     r2, #0  ; 0x0
   a1820264:       0a000077        beq     a1820448 <ext2fs_iterate_dir+0x254>

[so r2 is namelen]

   a1820268:       e282300f        add     r3, r2, #15     ; 0xf
   a182026c:       e2033f7e        and     r3, r3, #504    ; 0x1f8

so here r3 is (namelen + 0xf) & 0x1f8 . I don't understand the "&0x1f8" since
r2 was known to be 8 bits at most.

   a1820270:       e50bd034        str     sp, [fp, #-52]
   a1820274:       e063d00d        rsb     sp, r3, sp

stack pointer has been saved, and sp takes sp - r3. Looks fine.

   a1820278:       e1a041ad        lsr     r4, sp, #3
   a182027c:       e51b3030        ldr     r3, [fp, #-48]
   a1820280:       e1a0a184        lsl     sl, r4, #3

shift back and forth to align sp ("ldr r3" in the middle is fpos, used
in building arguments for ext2fs_read_file).

   a1820284:       e1a00007        mov     r0, r7
   a1820288:       e2831008        add     r1, r3, #8      ; 0x8
   a182028c:       e1a0300a        mov     r3, sl
   a1820290:       ebfffe77        bl      a181fc74 <ext2fs_read_file>


So everything looks fine. I also tried a standalone program with both
a uint16_t and the official uint8_t namelen and it works fine (there
is no "& 0x1f8" any more in the assembly for 16-bit lengths).  In that
test the callee has a stack pointer which is as low as needed according
to the namelen used by the caller.


Therefore, I suspect your problem can come out of
ext2fs_read_file. However, the calculations there look good to me
(actually, everybody uses them, so they must be good for normal uses).

However, in ext2fs_read_file, there might be an issue in the first
block (which "is not stored on disk but is zero filled instead"):

                        memset (buf, 0, blocksize - skipfirst);
should be
                        memset (buf, 0, blockend - skipfirst);

where blockend is == blocksize but might be shorter in the last block
of the read. So if you are reading a dirent in the first block you
might have a problem of stack overflow.

But I don't expect you'll read a dirent from first block, and even if
it was, then namelen would be zero as well.  I suspect your problem is
elsewhere, although I can't imagine where, as this code doesn't look
like something that can stack overflow even if misused.

/alessandro

[U-Boot] EABI 4.2

[Simon Kagstrom]

(Sorry if this has already been taken up, I've not been following the
discussion closely)

On Thu, 11 Mar 2010 11:11:09 +0100
"Martin Krause" <Martin.Krause@tqs.de> wrote:

> >> Does this mean, my toolchain is broken? I use ELDK4.2 for ARM.
> > 
> > I belive so, how many bytes is in dirent.namelen? alloca can not
>
> I compiled the original code with VLA with ELDK4.1 and there 
> everything works. And also the '__builtin_alloca' Version works
> with ELDK4.1.

I had a similar problem a few months ago, which turned out to be a
stack alignment issue:

  http://www.mail-archive.com/u-boot at lists.denx.de/msg23202.html

the behavior was pretty similar, with code built with some compilers
working (by chance) and some others breaking.

(The patch above is in U-boot since november something I think)

// Simon

[U-Boot] EABI 4.2

[Praveen G K]

On Wed, Mar 17, 2010 at 2:48 AM, Simon Kagstrom
<simon.kagstrom@netinsight.net> wrote:
> (Sorry if this has already been taken up, I've not been following the
> discussion closely)
>
> On Thu, 11 Mar 2010 11:11:09 +0100
> "Martin Krause" <Martin.Krause@tqs.de> wrote:
>
>> >> Does this mean, my toolchain is broken? I use ELDK4.2 for ARM.
>> >
>> > I belive so, how many bytes is in dirent.namelen? alloca can not
>>
>> I compiled the original code with VLA with ELDK4.1 and there
>> everything works. And also the '__builtin_alloca' Version works
>> with ELDK4.1.
>
> I had a similar problem a few months ago, which turned out to be a
> stack alignment issue:
>
> ?http://www.mail-archive.com/u-boot at lists.denx.de/msg23202.html
>
> the behavior was pretty similar, with code built with some compilers
> working (by chance) and some others breaking.

Great! This does work when added to cpu/arm1176/start.S
Is there any specific reason why this was not added to the arm11 stream?

> (The patch above is in U-boot since november something I think)
>
> // Simon
>

[U-Boot] EABI 4.2

[Simon Kagstrom]

On Wed, 17 Mar 2010 09:53:36 -0500
Praveen G K <praveen.gk@gmail.com> wrote:

> > I had a similar problem a few months ago, which turned out to be a
> > stack alignment issue:
> >
> > ?http://www.mail-archive.com/u-boot at lists.denx.de/msg23202.html
> >
> > the behavior was pretty similar, with code built with some compilers
> > working (by chance) and some others breaking.
> 
> Great! This does work when added to cpu/arm1176/start.S
> Is there any specific reason why this was not added to the arm11 stream?

Well, none other than that I didn't realise it affected other platforms
as well. Looking at the tip, it seems like pretty much all ARM
platforms are susceptible to this issue. So a mass-fix would probably
be in place.

// Simon

[U-Boot] EABI 4.2

[Wolfgang Denk]

Dear Tom,

In message <20100317161258.76fee35c@marrow.netinsight.se> Simon
Kagstrom wrote:
> On Wed, 17 Mar 2010 09:53:36 -0500
> Praveen G K <praveen.gk@gmail.com> wrote:
> 
> > > I had a similar problem a few months ago, which turned out to be a
> > > stack alignment issue:
> > >
> > > =A0http://www.mail-archive.com/u-boot at lists.denx.de/msg23202.html
> > >
> > > the behavior was pretty similar, with code built with some compilers
> > > working (by chance) and some others breaking.
> > =
> 
> > Great! This does work when added to cpu/arm1176/start.S
> > Is there any specific reason why this was not added to the arm11 stream?
> 
> Well, none other than that I didn't realise it affected other platforms
> as well. Looking at the tip, it seems like pretty much all ARM
> platforms are susceptible to this issue. So a mass-fix would probably
> be in place.

This seems serious enough to me that we should try to get this fixed
in the upcoming release.  Do you think you can manage this?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Einstein argued that there must be simplified explanations of nature,
because God is not capricious or arbitrary. No  such  faith  comforts
the software engineer.                             - Fred Brooks, Jr.

[U-Boot] EABI 4.2

[Wolfgang Denk]

Dear Tom,

In message <20100317084833.364b27fa@marrow.netinsight.se> Simon Kagstrom wrote:
> (Sorry if this has already been taken up, I've not been following the
> discussion closely)
> 
> On Thu, 11 Mar 2010 11:11:09 +0100
> "Martin Krause" <Martin.Krause@tqs.de> wrote:
> 
> > >> Does this mean, my toolchain is broken? I use ELDK4.2 for ARM.
> > > 
> > > I belive so, how many bytes is in dirent.namelen? alloca can not
> >
> > I compiled the original code with VLA with ELDK4.1 and there 
> > everything works. And also the '__builtin_alloca' Version works
> > with ELDK4.1.
> 
> I had a similar problem a few months ago, which turned out to be a
> stack alignment issue:
> 
>   http://www.mail-archive.com/u-boot at lists.denx.de/msg23202.html
> 
> the behavior was pretty similar, with code built with some compilers
> working (by chance) and some others breaking.
> 
> (The patch above is in U-boot since november something I think)

Is there any chance to have this fixed for all ARM variants during
this release cycle?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Man did not weave the web of life; he  is  merely  a  strand  in  it.
Whatever he does to the web, he does to himself.     - Seattle [1854]

[U-Boot] EABI 4.2

[Tom Rix]

Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20100317084833.364b27fa@marrow.netinsight.se> Simon Kagstrom wrote:
>> (Sorry if this has already been taken up, I've not been following the
>> discussion closely)
>>
>> On Thu, 11 Mar 2010 11:11:09 +0100
>> "Martin Krause" <Martin.Krause@tqs.de> wrote:
>>
>>>>> Does this mean, my toolchain is broken? I use ELDK4.2 for ARM.
>>>> I belive so, how many bytes is in dirent.namelen? alloca can not
>>> I compiled the original code with VLA with ELDK4.1 and there 
>>> everything works. And also the '__builtin_alloca' Version works
>>> with ELDK4.1.
>> I had a similar problem a few months ago, which turned out to be a
>> stack alignment issue:
>>
>>   http://www.mail-archive.com/u-boot at lists.denx.de/msg23202.html
>>
>> the behavior was pretty similar, with code built with some compilers
>> working (by chance) and some others breaking.
>>
>> (The patch above is in U-boot since november something I think)
> 
> Is there any chance to have this fixed for all ARM variants during
> this release cycle?
> 

Yes.  I will take this up.
Please send me some instruction on how to get just the eldk4.2 toolchain.
Tom

> Best regards,
> 
> Wolfgang Denk
> 

[U-Boot] EABI 4.2

[Detlev Zundel]

Hi Tom,

> Wolfgang Denk wrote:
>> Dear Tom,
>> 
>> In message <20100317084833.364b27fa@marrow.netinsight.se> Simon Kagstrom wrote:
>>> (Sorry if this has already been taken up, I've not been following the
>>> discussion closely)
>>>
>>> On Thu, 11 Mar 2010 11:11:09 +0100
>>> "Martin Krause" <Martin.Krause@tqs.de> wrote:
>>>
>>>>>> Does this mean, my toolchain is broken? I use ELDK4.2 for ARM.
>>>>> I belive so, how many bytes is in dirent.namelen? alloca can not
>>>> I compiled the original code with VLA with ELDK4.1 and there 
>>>> everything works. And also the '__builtin_alloca' Version works
>>>> with ELDK4.1.
>>> I had a similar problem a few months ago, which turned out to be a
>>> stack alignment issue:
>>>
>>>   http://www.mail-archive.com/u-boot at lists.denx.de/msg23202.html
>>>
>>> the behavior was pretty similar, with code built with some compilers
>>> working (by chance) and some others breaking.
>>>
>>> (The patch above is in U-boot since november something I think)
>> 
>> Is there any chance to have this fixed for all ARM variants during
>> this release cycle?
>> 
>
> Yes.  I will take this up.
> Please send me some instruction on how to get just the eldk4.2 toolchain.

ELDK4.2 is "atomic", i.e. you have to do a regular install to get the
toolchain[1].

Cheers
  Detlev

[1] http://www.denx.de/wiki/view/DULG/ELDKAvailability

-- 
The proprietary-Unix players proved so ponderous, so blind, and so inept at
marketing that Microsoft was able to grab away a large part of their market
with the shockingly inferior technology of its Windows operating system.
                   -- "A Brief History of Hackerdom" by Eric Steven Raymond
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de