On Fri, 2009-01-30 at 14:43 +0100, Vincent R. wrote:
> I also tried to generate a cegcc-4.4.0 but unfortuantely it DOESN'T WORK
> because it seems
> there is an issue with crtstuff. Indeed binaries starts at wrong virtual
> address !!!
I've not tried your patch yet (other urgent things to do this week,
sorry). The remark above caught my attention though.
What exactly is the problem, what does your toolchain pass to the linker
(cc -v), what does the crt*.o look like ?
Danny
P.S. I think current behaviour of the mingw toolchain is this :
- crt3.o is linked in with a command as shown below(from cc -v). Note
that crt3.o is the first module passed to the linker.
/opt/mingw32ce/libexec/gcc/arm-mingw32ce/4.3.2/collect2 -Bdynamic -o
menu.exe
/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.3.2/../../../../arm-mingw32ce/lib/crt3.o
-L/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.3.2
-L/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.3.2/../../../../arm-mingw32ce/lib
menu.o menu.rsc -laygshell -lcommctrl -lmingw32 -lgcc -lceoldname -lmingwex
-lcoredll -lcoredll -lmingw32 -lgcc -lceoldname -lmingwex -lcoredll
- crt3.o defines a couple of symbols/functions, but it is carefully
coded and ordered such that WinMainCRTStartupHandler is first in the
.text segment :
Disassembly of section .text:
00000000 <WinMainCRTStartupHandler>:
0: e92d40f0 push {r4, r5, r6, r7, lr}
4: e24dd00c sub sp, sp, #12 ; 0xc
8: e1a05000 mov r5, r0
c: e1a06002 mov r6, r2
...
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
