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 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
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
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
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
[U-Boot] Fwd: 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
[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
