On 27/01/2010 00:54, Sébastien Lorquet wrote:
> The latest toolchain, that produces the bug, is at:
> http://www.unsads.com/~squalyl/cegcc/mingw32ce-4.1-20100125.zip
I downloaded this zip and unpacked it to C:\ on a WinXpSp2 machine, then ran
PATH C:\mingw32ce-4.1-20100125\cross41\bin;%PATH%
> Simplest test case:
>
> #include <windows.h>
> int APIENTRY WinMain(HINSTANCE inInstance, HINSTANCE inPrevInst, LPWSTR
> inCmdLine, int inCmdShow)
> {
> MessageBoxW(NULL, L"hello", L"hello", MB_ICONINFORMATION);
> return 0;
> }
>
> compiles fine under linux with both
> arm-mingw32ce-gcc test.c -o test.exe
> and
> arm-mingw32ce-gcc -g test.c -o test.exe
>
> But with my toolchain, cross compiled from linux to mingw32msvc, the second
> line fails.
So... are we sure we're testing the same thing? Because it worked fine for
me:
C:\mingw32ce-4.1-20100125>dir
Volume in drive C has no label.
Volume Serial Number is 6857-454C
Directory of C:\mingw32ce-4.1-20100125
31/01/2010 16:40 <DIR> .
31/01/2010 16:40 <DIR> ..
31/01/2010 16:37 <DIR> cross41
31/01/2010 16:34 209 test.c
1 File(s) 209 bytes
3 Dir(s) 17,257,099,264 bytes free
C:\mingw32ce-4.1-20100125>type test.c
#include <windows.h>
int APIENTRY WinMain(HINSTANCE inInstance, HINSTANCE inPrevInst, LPWSTR
inCmdLine, int inCmdShow)
{
MessageBoxW(NULL, L"hello", L"hello", MB_ICONINFORMATION);
return 0;
}
C:\mingw32ce-4.1-20100125>arm-mingw32ce-gcc -g test.c -o test.exe
C:\mingw32ce-4.1-20100125>dir
Volume in drive C has no label.
Volume Serial Number is 6857-454C
Directory of C:\mingw32ce-4.1-20100125
31/01/2010 16:40 <DIR> .
31/01/2010 16:40 <DIR> ..
31/01/2010 16:37 <DIR> cross41
31/01/2010 16:34 209 test.c
31/01/2010 16:40 28,753 test.exe
2 File(s) 28,962 bytes
3 Dir(s) 17,257,066,496 bytes free
C:\mingw32ce-4.1-20100125>arm-mingw32ce-objdump -h test.exe
test.exe: file format pei-arm-wince-little
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000788 00011000 00011000 00000400 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00000020 00012000 00012000 00000c00 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .rdata 0000029c 00013000 00013000 00000e00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .debug_aranges 000000e0 00014000 00014000 00001200 2**0
CONTENTS, READONLY, DEBUGGING
4 .debug_pubnames 000001f9 00015000 00015000 00001400 2**0
CONTENTS, READONLY, DEBUGGING
5 .debug_info 000013b3 00016000 00016000 00001600 2**0
CONTENTS, READONLY, DEBUGGING
6 .debug_abbrev 00000682 00018000 00018000 00002a00 2**0
CONTENTS, READONLY, DEBUGGING
7 .debug_line 00000740 00019000 00019000 00003200 2**0
CONTENTS, READONLY, DEBUGGING
8 .debug_frame 00000258 0001a000 0001a000 00003a00 2**2
CONTENTS, READONLY, DEBUGGING
9 .debug_str 0000004e 0001b000 0001b000 00003e00 2**0
CONTENTS, READONLY, DEBUGGING
10 .debug_loc 00000646 0001c000 0001c000 00004000 2**0
CONTENTS, READONLY, DEBUGGING
11 .debug_ranges 00000070 0001d000 0001d000 00004800 2**0
CONTENTS, READONLY, DEBUGGING
C:\mingw32ce-4.1-20100125>
On 31/01/2010 11:32, Sébastien Lorquet wrote:
> According to the code, the incriminated lines are:
>
> /* Flag that this BFD uses long names, even though the format might
> expect them to be off by default. This won't directly affect the
> format of any output BFD created from this one, but the information
> can be used to decide what to do. */
> bfd_coff_set_long_section_names (abfd, TRUE);
> memcpy (buf, hdr->s_name + 1, SCNNMLEN - 1);
> buf[SCNNMLEN - 1] = '\0';
> strindex = strtol (buf, &p, 10);
> if (*p == '\0' && strindex >= 0)
> {
> strings = _bfd_coff_read_string_table (abfd);
> if (strings == NULL)
> return FALSE;
> * /* FIXME: For extra safety, we should make sure that
> strindex does not run us past the end, but right now we
> don't know the length of the string table. */
> * strings += strindex;
> name = (char *) bfd_alloc (abfd,
> (bfd_size_type) *strlen (strings)* +
> 1);
> if (name == NULL)
> return FALSE;
> strcpy (name, strings);
> }
> (gdb) print *hdr
> $10 = {s_name = "/8976241", s_paddr = 0, s_vaddr = 0, s_size = 145, s_scnptr
> = 572, s_relptr = 0, s_lnnoptr = 0, s_nreloc = 0, s_nlnno = 0, s_flags =
> 1108344832, s_align = 21807152, s_page = 20 '\024'}
Now, this should be a section header from the input .o file (created
temporarily during compilation since not using --save-temps), and some of
those values look right, but the s_name, which is meant to be a decimal offset
into the string table (at the end of the .o file) is clearly nonsensical.
>
> I don't know why the heck this happens, but the address out of bounds I get
> seems related to this FIXME .
The FIXME is stating that it would be nice if we could detect this kind of
malformed input here, but we (for structural reasons) can't. The problem has
to be either that the assembler generated a bogus .o file in the first place,
or that ld is somehow corrupting or misreading that section header.
Since I can't reproduce this problem, can you try recompiling your testcase,
using --save-temps, and then show us the output of "arm-mingw32ce-objdump -h
test.o" ?
cheers,
DaveK
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
