Hi Pedro, a few weeks ago a cegcc user called Jerome Decoodt posted on this ML to report that a DLL compiled with cegcc (or mingw32ce) couldn't be loaded if its size was bigger that 64 KB on WM6.1.
I have tested on a WM6.1 device and actually when I tried to load a sample DLL here is what I see on a device with a debug ROM : CreateProcess(bc3e002,NK.EXE,84928000) >>>[Processes Info]<<< [P C2000000 0BC3E002 00000001 'NK.EXE'] [M 03F5B000 00087000 'coredll.dll'] [M 8497D000 0000C000 'osaxst0.dll'] [M 84979000 00004000 'hd.dll'] ... Relaunching: \Temp\testDLLexe.exe CreateProcess(69baa84a,testDLLexe.exe,30000000) CertVerify: \Temp\testDLLexe.exe trust = 2 LoadDLL(69baa84a,8bc3e7e0,coredll.dll,03f5b000) CertVerify: testDLL.dll trust = 2 LoadDLL(ffffffff,89bc53cc,testdll.dll,78690000) Data Abort: Thread=8a391ab0 Proc=84b98350 '' AKY=00c00001 PC=8494f630(NK.EXE+0x00027630) RA=000000e4(???+0x000000e4) BVA=786a9000 FSR=00000007 EXCEPTION_RECORD(c0000005(EXCEPTION_ACCESS_VIOLATION),0(continuable),0,8494f630,2) ExceptionInformation: 0 : 0 1 : 786a9000 === ThreadInfo 8A391AB0 === Proc = 84b98350 Owner Proc = 84b98350 Stack Base= c2090000 StartAddr = 8495592c >>>[Callstack 8A391AB0]<<< [1 8496962C] <<<< NK.EXE+0x0004162C : fast_decode_verbatim_block 00051568 f nk:decverb.obj [2 84969C78] <<<< NK.EXE+0x00041C78 : fast_decode_aligned_offset_block 00051bfc f nk:decalign.obj [3 849419D0] <<<< NK.EXE+0x000199D0 : SC_CreateProc 0002961c f nk:schedule.obj [4 84933B84] <<<< NK.EXE+0x0000BB84 : ServerCallReturn 0001ba98 f nk:objdisp.obj [5 8492F470] <<<< NK.EXE+0x00007470 : [EMAIL PROTECTED]@[EMAIL PROTECTED]@ 00017448 kitl:ethdbg.obj [6 8494F630] <<<< NK.EXE+0x00027630 : SetROMDllBase 00037318 f nk:loader.obj [7 84954790] <<<< NK.EXE+0x0002c790 : LoaderPageIn 0003c584 f nk:loader.obj [8 8494F680] <<<< NK.EXE+0x00027680 : CloseExe 00037678 f nk:loader.obj [9 8495566C] <<<< NK.EXE+0x0002D66C : FreeOneLibrary 0003d4bc f nk:loader.obj [10 84955A44]<<<< NK.EXE+0x0002DA44 : InitModule 0003da30 f nk:loader.obj <<<[Callstack]>>> R0=89bc543c R1=89bfad08 R2=84b95f7c R3=00019000 R4=89bc543c R5=00000000 R6=89bfad08 R7=00000002 R8=78690000 R9=786a9000 R10=786a9000 R11=c209fd4c R12=c209fd5c SP=c209fc88 Lr=000000e4 PC=8494f630 Psr=6000001f TerminateProcess(69baa84a) DeleteProcess(69baa84a) I tried to map the corresponding stack address to the corresponding functions but mapping may be totally wrong. Anyway there is an issue with PE loader in new WM6.1 OS and its related to a new feature described here : http://bolingconsulting.com/blog/?p=4 "The problem with memory in Windows Mobile has always been the vast number of DLLs in the system. DLLs are loaded from the top of slot 1 down. Since there are so many DLLs in the system, not only do they fill up slot 1, they encroach into slot 0. This leaves only about 18-20 Meg of virtual space for each application. This problem is most acute in the Device Manager process space where dozens of device drivers, each with their own interrupt service thread, tended to consume most of the virtual space in that process. This slot arrangement remained pretty constant from Windows Mobile 2003 to Windows Mobile 6.0. However, with the release of Windows Mobile 6.1, things were changed to reduce the DLL pressure and to help out in the Device Manager process space. In Windows Mobile 6.1, the stacks for the device manager are no longer allocated in the processes’ slot. Instead, the operating system uses slot 59, at the top of the Large Memory Area, for the device manager thread stacks. In addition to the stack move, changes were also made in where DLLs are placed. While execute-in-place(XIP) DLLs are still loaded from the top of Slot 1, any DLL that is larger than 64 KB and isn’t XIP is loaded in slot 60. If the 32 MB of slot 60 fills up with DLLs, the OS uses slot 61 for the DLLs. This additional 64 MB of DLLs space should go a long way in reducing the problem of too many DLLs in Windows Mobile systems." If you want to test and have Visual Studio you can download a WM6.1 emulator ROM and tried the sample code I have attached. The workaround for this issue seems to declare the DLL in registry to tell the OS not to load the DLL in high memory. Vincent R.
testDLL.tar.gz
Description: GNU Zip compressed data
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
