Re: puzzled - old release works, newer doesn't

[Danny Backx <danny.backx@scarlet.be>]

[-- Attachment #1: Type: text/plain, Size: 5686 bytes --]

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]  
   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  
   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   
   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,
> 
> > 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".
> > 
> > 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.
> > 
> > My personal experience with the 2.16 release appears to confirm that.
> 
> Are you upgrading to the new GCC new GAS and new LD all at the same time 
> ?  If not then that might be the cause.
> 
> Are you aware of the --support-old-code linker switch which is specific 
> to the arm-wince-pe target ?  Using this might help you.
> 
> Using the latest binutils sources from CVS repository might also help. 
> If not then I would recommend comparing a disassembly of a working 
> binary and broken binary to see where there are changes.  (Do not 
> compare the object files, but linked binaries.  This should allow you to 
> find out how relocs may have been processed differently).
> 
> Cheers
>    Nick
> 
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]