Subject: Re: cegcc 4.4 failure

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.

------------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/cegcc-devel