From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alessandro Rubini Date: Tue, 16 Mar 2010 23:18:45 +0100 Subject: [U-Boot] EABI 4.2 In-Reply-To: References: <47F3F98010FF784EBEE6526EAAB078D10635E68D@tq-mailsrv.tq-net.de> Message-ID: <20100316221845.GA12753@morgana.gnudd.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 [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 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