Re: [U-Boot] EABI 4.2
Hi Tom, Wolfgang Denk wrote: Dear Tom, In message 20100317084833.364b2...@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.kra...@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@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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
Wolfgang Denk wrote: Dear Tom, In message 20100317084833.364b2...@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.kra...@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@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
Dear Tom, In message 20100317084833.364b2...@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.kra...@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@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: w...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
Dear Tom, In message 20100317161258.76fee...@marrow.netinsight.se Simon Kagstrom wrote: On Wed, 17 Mar 2010 09:53:36 -0500 Praveen G K praveen...@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@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: w...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
(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.kra...@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@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
On Wed, Mar 17, 2010 at 2:48 AM, Simon Kagstrom simon.kagst...@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.kra...@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@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
On Wed, 17 Mar 2010 09:53:36 -0500 Praveen G K praveen...@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@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
On Fri, Mar 12, 2010 at 11:12 AM, Praveen G K praveen...@gmail.com wrote: On Fri, Mar 12, 2010 at 3:04 AM, Detlev Zundel d...@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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
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: e55b2026ldrbr2, [fp, #-38]
a1820260: e352cmp r2, #0 ; 0x0
a1820264: 0a77beq a1820448 ext2fs_iterate_dir+0x254
[so r2 is namelen]
a1820268: e282300fadd r3, r2, #15 ; 0xf
a182026c: e2033f7eand 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: e50bd034str sp, [fp, #-52]
a1820274: e063d00drsb sp, r3, sp
stack pointer has been saved, and sp takes sp - r3. Looks fine.
a1820278: e1a041adlsr r4, sp, #3
a182027c: e51b3030ldr r3, [fp, #-48]
a1820280: e1a0a184lsl 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: e1a7mov r0, r7
a1820288: e2831008add r1, r3, #8 ; 0x8
a182028c: e1a0300amov r3, sl
a1820290: ebfffe77bl 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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
On Fri, Mar 12, 2010 at 3:04 AM, Detlev Zundel d...@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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
Joakim Tjernlund wrote on Wednesday, March 10, 2010 6:29 PM: Martin Krause martin.kra...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
On Thu, Mar 11, 2010 at 4:11 AM, Martin Krause martin.kra...@tqs.de wrote: Joakim Tjernlund wrote on Wednesday, March 10, 2010 6:29 PM: Martin Krause martin.kra...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
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 ... Regards, Martin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
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 ... 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
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.kra...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
Dear Praveen G K, In message fe7c83ac1003100644s5603e196i5d00066abe5d8...@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: w...@denx.de Panic, n.: The second time you can't do it the first time. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
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: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
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
Re: [U-Boot] EABI 4.2
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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] EABI 4.2
Martin Krause martin.kra...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] EABI 4.2
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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
