------- Additional Comments From KenJackson at ieee dot org  2006-02-22 14:52 
-------
I've simplified it by stripping away all gcc influence.  This is purely
a binutils bug.  I suspect it is ld's relocation that is causing the
problem.  Or maybe it's the BFD library, if that's a separate entity.


Source file, a.S:
        .comm x,16,1
        .global main
    main:
        cpi  r26,lo8(__bss_end)
        cpi  r26,lo8(16)

Compile script:
    avr-as a.S -o a.o
    avr-ld -m avr4 -Tdata 0x800100 -o a.elf  a.o
    avr-objdump -d a.elf > a.lst
    avr-ld -m avr4 -Tdata 0x800100 -o a.hex --oformat=ihex  a.o

Output file a.lst, lines 7,8:
    0:   a0 31           cpi r26, 0x10   ; 16
    2:   a0 31           cpi r26, 0x10   ; 16

Output file a.hex:
    :04000000B031A0314A
    :00000001FF


The list file shows both opcodes correctly, "a0 31".  But in the hex file
the first one is wrong, "B031", while the second one is correct, "A031".

The difference is that avr-ld had to do a relocation for the first one.
Running "avr-objdump -r a.o" shows one record with type R_AVR_LO8_LDI
relocation, value __bss_end.

R_AVR_LO8_LDI is performed in binutils-2.16.1/bfd/elf32-avr.c.  It works
correctly for the default ELF format, but fails for the IHEX format.

This is progress, but I'm still stumped.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2378

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils

Reply via email to