Re: [avr-gcc-list] tool chain bug

[Theodore A. Roth]

The bug is in the latest cvs version of gas. The AVRFREAKs dist is based
on earlier versions of the software which don't have the problem.

I spent most of yesterday trying to track it down. From what I can tell
the problem occurs when the assembler sees an insn with a 7-bit
pc-relatice offset which doesn't have an associated symbol. The lack of a
symbol seems to confuse the assembler and it never performs a relocation
fixup, thus the offset gets inserted into the insn as zero.

Ted Roth

On Wed, 25 Sep 2002 address@hidden wrote:

:)
:) Hum...
:)
:) I know this is not very helpful (maybe not helpful at all), but when I
:) compile your example, for an ATmega128, I get slightly different code, but
:) it appears to be correct.  I am using the AVRFREAKS distribution package
:) from June...
:)
:)   81 0008 26E0                ldi r18,lo8(6)
:)   82 000a DE01                movw r26,r28
:)   83 000c 1196                adiw r26,1
:)   84 000e E0E0                ldi r30,lo8(foo)
:)   85 0010 F0E0                ldi r31,hi8(foo)
:)   86 0012 0190                ld __tmp_reg__,Z+
:)   87 0014 0D92                st X+,__tmp_reg__
:)   88 0016 2A95                dec r18
:)   89 0018 E1F7                brne _PC_-8
:)
:)
:)
:)
:) Robert M. Beatty
:) Director Systems Engineering
:) The Watt Stopper Inc.
:) P: 401.562.4108
:) F: 401.562.4150
:) E: address@hidden
:)
:)
:)
:)                       "Theodore A.
:)                       Roth"                    To:       Marek Michalkiewicz 
<address@hidden>, Denis
:)                       <address@hidden         Chertykov <address@hidden>
:)                       m>                       cc:       AVR GCC List 
<address@hidden>
:)                       Sent by:                 Subject:  [avr-gcc-list] tool 
chain bug
:)                       owner-avr-gcc-lis
:)                       address@hidden
:)
:)
:)                       09/24/02 05:28 PM
:)
:)
:)
:)
:)
:)
:) I noted this on the list before and there was no response so I've
:) investigated a bit more. (I synced up with cvs yesterday)
:)
:) Here's a simple program which demostrates the bug:
:)
:) cat <<EOF > messy.c
:) #include <string.h>
:) #include <inttypes.h>
:)
:) uint8_t foo[6] = {0, 1, 2, 3, 4, 5};
:)
:) void main (void)
:) {
:)     uint8_t bar[6];
:)     memcpy (bar,foo,6);
:)
:) }
:) EOF
:)
:) Compiling as such:
:)
:) avr-gcc -g -O2 -Wall -mmcu=atmega128   -c -o messy.o messy.c
:) avr-gcc -g -O2 -Wall -mmcu=atmega128 -Wl,-Map,messy.map -o messy messy.o
:) messy.o(.text+0x18): In function `main':
:) /home/roth/dev/messy/messy.c:13: relocation truncated to fit: R_AVR_7_PCREL
:) no symbol
:)
:) And disassembling messy.o with `avr-objdump -S messy.o` yields this:
:)
:)     memcpy (bar,foo,6);
:)    8:   86 e0           ldi     r24, 0x06       ; 6
:)    a:   de 01           movw    r26, r28
:)    c:   11 96           adiw    r26, 0x01       ; 1
:)    e:   e0 e0           ldi     r30, 0x00       ; 0
:)   10:   f0 e0           ldi     r31, 0x00       ; 0
:)   12:   01 90           ld      r0, Z+
:)   14:   0d 92           st      X+, r0
:)   16:   8a 95           dec     r24
:)   18:   01 f4           brne    .+0             ; 0x1a
:)
:) If I go back to the cvs versions of binutils/gcc from 20020903, which work
:) for me, I get this code:
:)
:)     memcpy (bar,foo,6);
:)    8:   86 e0           ldi     r24, 0x06       ; 6
:)    a:   de 01           movw    r26, r28
:)    c:   11 96           adiw    r26, 0x01       ; 1
:)    e:   e0 e0           ldi     r30, 0x00       ; 0
:)   10:   f0 e0           ldi     r31, 0x00       ; 0
:)   12:   01 90           ld      r0, Z+
:)   14:   0d 92           st      X+, r0
:)   16:   8a 95           dec     r24
:)   18:   e1 f7           brne    .-8             ; 0x12
:)
:) Notice that the "brne" insn at addr 0x18 is messed up.
:)
:) I have some other code that exhibits the same problem but with "breq" and
:) "brcc" insns.
:)
:) I'm not really sure as to which program has the bug, gcc or gas, but
:) whoever it is, is generating bogus code.
:)
:) I'll keep digging and see if I can come up with a fix, but I'm really
:) groping in the dark on this one right now.
:)
:)
:) Ted Roth
:)
:) avr-gcc-list at http://avr1.org
:)
:)
:)
:)
:)

avr-gcc-list at http://avr1.org