Kevin O'Connor escreveu:
> Hi,
>
> I've received a report that haret does not run on wince 2.1 machines.
> I've confirmed that this isn't a linker issue. The application seems
> to crash before calling into WinMain.
>
> Has anyone tested mingw32ce c++ on ce 2.1?
>
> To debug this, I changed my linker line to use "-e WinMain". The
> application will then startup and run for a while. (It goes on to
> crash because some classes aren't initialized correctly, but I've got
> logs showing the program does run.) Without overriding the start
> point, the app does not appear to get to WinMain.
>
>
> Any ideas on what would make the app crash prior to WinMain? I've
> looked through my code with objdump and inspected all the
> "__static_initialization" code and there is nothing even remotely
> complicated going on. I do see cegcc adding calls to eh_globals.cc,
> but I've got no idea what that does.
>
> I have no issues with the same app my wince 5.0 machine. My link line
> looks like:
>
> /home/kevin/src/vx6700/haret/toolchain-cegcc/bin/arm-wince-mingw32ce-g++
> -Wl,--major-subsystem-version=2,--minor-subsystem-version=1 ... -o
> haret-debug
>
> -Kevin
>
>
Well, hard to say, but I will dump some ideas, that hopefully will be
helpful.
It is 'main' that is responsable for calling __gccmain (that call gets
inserted there by gcc automatically).
__gccmain is responsible for calling the c++ global constructors.
Even if you don't define a main in your code, there is one
on libmingw.a that gets linked in, and that is what normally calls WinMain.
The normal entry point is WinMainCRTStartup, and it goes like this
(simplified):
src/mingw/crt1.c:
WinMainCRTStartup
(setup argc/argv)
(resolve runtime pseudo relocs)
(initialize at exit tables)
main -> calls __gccmain
WinMain
If you define WinMain as the entry point, the
c++ global constructors will not run.
You can use that to test if the problem comes from one of your global
ccs. Use -e WinMain,
and then after you are sure the app is running, eg. MessageBoxW(0,
L"hello", L"h3llo", 0)
which always works without any other runtime initialization, call
__gccmain. If that hangs, there is
a good chance you are doing something not supported by ce2.1.
extern "C" void __gccmain();
WinMain
{
MessageBoxW(0, L"test", L"got here", 0);
__gccmain();
MessageBoxW(0, L"test", L"got here 2", 0);
}
Try adding -D_WIN32_WCE=0x200 to CFLAGS in your Makefile.
There are some win32 structures that had some fields added in later
versions of WinCE.
I have never seen a WinCE < 3 machine, and I don't really know for sure
what may be different there.
Currently all the toolchain is built with CE 3 as the default (linker
and headers).
I also remember seeing some comments on gas code about something about
the relocs being different in
CE2/CE3, but I think I deleted / rewrote that part of the code, a few
months ago, can't remember correctly.
Long shot, but some function may have been wrongly relocated by the loader.
Did it work with the VLC toolchain?
Could it be that we are emitting some arm insns that that pda's
processor doesn't support? We are defaulting
to armv4.
But (most probably) you are calling some function that is not supported
by WinCE 2 that then returns
a NULL of an invalid handle, that you are not checking?
Just guessing, hope that helps.
Cheers,
Pedro Alves
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
