Uurgh, I totally missed this message before posting the other one... I've posted an updated patch against trunk at cegcc-de...@. It should fix the alignment issue. ".align FOO" on ARM coff works like on elf, that is, FOO is power 2 aligment... I've also fixed a couple of __dllimport issues on ARM, so I wouldn't be suprised if the malloc issue is gone, but I haven't really spend more than 10 seconds looking at your report yet. (Sorry, I'm swamped at the moment).
On Friday 13 February 2009 18:44:14, Vincent R. wrote: > Hi, > > I have updated the patch to generate a cegcc based on gcc-trunk. > There have been some changes in the way to generate shared libgcc so I have > updated > config.gcc and t-wince-pe > (http://www.nabble.com/-PATCH--Fix-PR38904:-mis-named-libgcc-DLL-on-cygwin.-td21609057.html): > > config.gcc: > > ... > + if test x$sjlj = x0; then > + tmake_eh_file="i386/t-dw2-eh" > + else > + tmake_eh_file="i386/t-sjlj-eh" > + fi > + tmake_file="${tmake_file} ${tmake_eh_file} arm/t-arm arm/t-wince-pe > arm/t-cygming arm/t-mingw32" > ... > > Unfortunately code generated with cegcc-4.4 seems to be invalid and is not > loaded anymore, even on WM5. > For now don't know why. > To be more precise , DLL(testDll.dll) generated with cegcc-4.4 can be > loaded by an application(testDllexe.exe) > compiled with cegcc-4.1 but the same application compiled with cegcc-4.4 > cannot load it. > Amongst differences on testDllexe.exe between 4.1.0 and 4.4.0, there are > > 1) alignement > > with cegcc-4.4.0 & VS2008 > > .text:00011000 > .text:00011000 ; Segment type: Pure code > .text:00011000 AREA .text, CODE, READWRITE, ALIGN=4 > .text:00011000 ; ORG 0x11000 > .text:00011000 CODE32 > > with cegcc-4.1.0 > > .text:00011000 > .text:00011000 ; Segment type: Pure code > .text:00011000 AREA .text, CODE, READWRITE > .text:00011000 ; ORG 0x11000 > .text:00011000 CODE32 > > > and I have noticed some weird things about PE section characteristics but > not sure this is the > right direction. > For instance from what I understand align directive modify alignment in DLL > charcteristics, that's why > we have 0x00500000 ie IMAGE_SCN_ALIGN_16BYTES while when there is no align > directive default is > 0x00300000 IMAGE_SCN_ALIGN_4BYTES > > I don't really understand why .ALIGN 4 generates a IMAGE_SCN_ALIGN_16BYTES > by the way ... > > .text: 60500020h > .data: C0500040h > .rdata: 40500040h > .bss: C0500080h > .idata: C0300040h > > so you can see that .idata has a different alignment from other sections, I > am not saying this is the problem > but I think there might be some thniking about how alignment is handled in > binutils. > I may ask on their ML to have more information about that. > I tried to force in binutils to have the same alignement and it doesn't fix > it but I find it more > logical to keep same alignment on all sections. > > 2) GCC now is handling malloc import differently and gcc is testing if it > can loads libgcj_s.dll > > > > .text:0001153C malloc ; CODE XREF: > sub_11390+8p > .text:0001153C LDR R12, =__imp_malloc > .text:00011540 LDR PC, [R12] > .text:00011540 ; End of function malloc > .text:00011540 > .text:00011540 ; > --------------------------------------------------------------------------- > .text:00011544 off_11544 DCD __imp_malloc ; DATA XREF: > mallocr > .text:00011548 ALIGN 0x10 > .text:00011550 STMFD SP!, {R11,LR} > .text:00011554 ADD R11, SP, #4 > .text:00011558 BL sub_11060 > .text:0001155C LDR R0, =loc_110C0 > .text:00011560 LDMFD SP!, {R11,LR} > .text:00011564 B sub_112B0 > .text:00011564 ; > --------------------------------------------------------------------------- > > > .text:00011060 sub_11060 ; CODE XREF: > .text:00011558p > .text:00011060 > .text:00011060 var_4 = -4 > .text:00011060 > .text:00011060 STMFD SP!, {R4,R11,LR} > .text:00011064 LDR R3, =unk_12010 > .text:00011068 ADD R11, SP, #0xC+var_4 > .text:0001106C LDR R3, [R3] > .text:00011070 CMP R3, #0 > .text:00011074 LDMEQFD SP!, {R4,R11,PC} > .text:00011078 LDR R0, =aLibgcj_s_dll > .text:0001107C BL GetModuleHandleW > .text:00011080 CMP R0, #0 > .text:00011084 BEQ loc_11094 > .text:00011088 LDR R1, =a_jv_registercl > .text:0001108C BL GetProcAddressW > .text:00011090 MOV R4, R0 > .text:00011094 > .text:00011094 loc_11094 ; CODE XREF: > sub_11060+24j > .text:00011094 CMP R4, #0 > .text:00011098 LDMEQFD SP!, {R4,R11,PC} > .text:0001109C LDR R0, =unk_12010 > .text:000110A0 MOV LR, PC > .text:000110A4 MOV PC, R4 > .text:000110A8 LDMFD SP!, {R4,R11,PC} > .text:000110A8 ; End of function sub_11060 > > > Once again I don't know if it's the reason executable doesnt' load the DLL > but it's > a difference to notice. > > > > > > > > Vincent R. > > -- Pedro Alves ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
