From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21276 invoked by alias); 26 Apr 2006 20:07:18 -0000 Received: (qmail 21049 invoked by uid 22791); 26 Apr 2006 20:07:16 -0000 X-Spam-Check-By: sourceware.org Received: from xizor.is.scarlet.be (HELO xizor.is.scarlet.be) (193.74.71.21) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 26 Apr 2006 20:07:12 +0000 Received: from ([62.235.205.189]) by xizor.is.scarlet.be with ESMTP id k3QK77K10987; Wed, 26 Apr 2006 22:07:07 +0200 Received: from dannypc (dannypc [10.1.1.2]) by firewall.scarlet.be (8.12.2/8.12.3/SuSE Linux 0.6) with ESMTP id k3QK70qQ003877; Wed, 26 Apr 2006 22:07:00 +0200 Subject: Re: puzzled - old release works, newer doesn't From: Danny Backx To: Nick Clifton Cc: binutils In-Reply-To: <444E5ABD.8070209@redhat.com> References: <1144794175.3705.14.camel@dannypc> <444E5ABD.8070209@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4kgIDKMkh6Y4oq9m964a" Date: Thu, 27 Apr 2006 01:32:00 -0000 Message-Id: <1146082022.4109.25.camel@dannypc> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3-10mdk X-DCC-scarlet.be-Metrics: xizor 2020; Body=3 Fuz1=3 Fuz2=3 X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00386.txt.bz2 --=-4kgIDKMkh6Y4oq9m964a Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-length: 5608 Nick & others, Thanks for the input, but the --support-old-code flag doesn't appear to be the answer. And yes I am trying to replace GCC, GAS, and LD at the same time, I'm currently playing with binutils from CVS. No improvement from that either. I did some more digging since my last message, below I'll indicate what I see. The hello.s I use is still the same. As you said, the output pasted in below is from the fully linked exe file, not the .obj file. The executables I create from hello.s lack at least in two areas : - branches are off - references to literal strings are off In the piece below, you'll see that the statement at 11044 branches to an address 8 bytes too far to reach _fopen, also at 1106c and further you'll see three pointers all pointing to the same address. This is wrong too. The piece produced by the new compiler+binutils : 0001101c <_WinMain>: 1101c: e1a0c00d mov ip, sp 11020: e92dd800 stmdb sp!, {fp, ip, lr, pc} 11024: e24cb004 sub fp, ip, #4 ; 0x4 11028: e24dd014 sub sp, sp, #20 ; 0x14 1102c: e50b0010 str r0, [fp, #-16] 11030: e50b1014 str r1, [fp, #-20] 11034: e50b2018 str r2, [fp, #-24] 11038: e50b301c str r3, [fp, #-28] 1103c: e59f0028 ldr r0, [pc, #40] ; 1106c <_WinMain+0x50> 11040: e59f1028 ldr r1, [pc, #40] ; 11070 <_WinMain+0x54> 11044: eb0005da bl 127b4 <_fopen+0x8> 11048: e1a03000 mov r3, r0 1104c: e50b3020 str r3, [fp, #-32] 11050: e51b0020 ldr r0, [fp, #-32] 11054: e59f1018 ldr r1, [pc, #24] ; 11074 <_WinMain+0x58> 11058: eb0005de bl 127d8 <_fprintf+0x8> 1105c: e51b0020 ldr r0, [fp, #-32] 11060: eb0005e4 bl 127f8 <_fclose+0x8> 11064: e3a00000 mov r0, #0 ; 0x0 11068: eb00061b bl 128dc <_exit+0x8> 1106c: 00023000 andeq r3, r2, r0 11070: 00023000 andeq r3, r2, r0 11074: 00023000 andeq r3, r2, r0 For reference, here is a similar piece produced with old compiler +binutils : 0001101c <_WinMain>: 1101c: e1a0c00d mov ip, sp 11020: e92dd800 stmdb sp!, {fp, ip, lr, pc} 11024: e24cb004 sub fp, ip, #4 ; 0x4 11028: e24dd014 sub sp, sp, #20 ; 0x14 1102c: e50b0010 str r0, [fp, #-16] 11030: e50b1014 str r1, [fp, #-20] 11034: e50b2018 str r2, [fp, #-24]=20=20 11038: e50b301c str r3, [fp, #-28] 1103c: e59f0028 ldr r0, [pc, #40] ; 1106c <_WinMain+0x50> 11040: e59f1028 ldr r1, [pc, #40] ; 11070 <_WinMain+0x54> 11044: eb0005d8 bl 127ac <_fopen> 11048: e1a03000 mov r3, r0=20=20 1104c: e50b3020 str r3, [fp, #-32] 11050: e51b0020 ldr r0, [fp, #-32] 11054: e59f1018 ldr r1, [pc, #24] ; 11074 <_WinMain+0x58> 11058: eb0005dc bl 127d0 <_fprintf> 1105c: e51b0020 ldr r0, [fp, #-32] 11060: eb0005e2 bl 127f0 <_fclose> 11064: e3a00000 mov r0, #0 ; 0x0=20=20=20 11068: eb000619 bl 128d4 <_exit> 1106c: 00023000 andeq r3, r2, r0 11070: 0002301c andeq r3, r2, ip, lsl r0 11074: 00023020 andeq r3, r2, r0, lsr #32 In both cases, the pointers should refer to this : Contents of section .rdata: 23000 2f73746f 72616765 20636172 642f6465 /storage card/de 23010 76656c2f 6c6f672e 74787400 77000000 vel/log.txt.w... 23020 48656c6c 6f0d0a00 57434554 52414345 Hello...WCETRACE There might be other problems with the file produced, these are the ones I discovered. Unfortunately they appear more than enough reason for the executable not to do anything sensible :-( Quite frankly I have just started looking into binutils so its source is still a mystery so all clues are appreciated. I haven't bothered testing the recent pre-release. Danny On Tue, 2006-04-25 at 18:22 +0100, Nick Clifton wrote: > Hi Danny, >=20 > > The old environment is based on gcc 3.4.2, gas 2.13.2, binutils 2.15. > > (Yes there's a mixup there.) The new environment is using gcc 4.1 and > > binutils 2.16. In all versions, the target platform is "arm-wince-pe". > >=20 > > The person who created this distribution explains the mixup by saying > > that the GAS from 2.13 works, whereas the one in newer binutils doesn't. > >=20 > > My personal experience with the 2.16 release appears to confirm that. >=20 > Are you upgrading to the new GCC new GAS and new LD all at the same time= =20 > ? If not then that might be the cause. >=20 > Are you aware of the --support-old-code linker switch which is specific=20 > to the arm-wince-pe target ? Using this might help you. >=20 > Using the latest binutils sources from CVS repository might also help.=20 > If not then I would recommend comparing a disassembly of a working=20 > binary and broken binary to see where there are changes. (Do not=20 > compare the object files, but linked binaries. This should allow you to= =20 > find out how relocs may have been processed differently). >=20 > Cheers > Nick >=20 --=20 Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info --=-4kgIDKMkh6Y4oq9m964a Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part Content-length: 191 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBET9LmNEE+KCROU2kRAs08AJ9DOogghXryyk2HVgU/voO9L+g1mACfTAJo QMy7Uid4t2pZmFH77LkUcDY= =OxxD -----END PGP SIGNATURE----- --=-4kgIDKMkh6Y4oq9m964a--