avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] problems with linker


From: Theodore A. Roth
Subject: Re: [avr-gcc-list] problems with linker
Date: Wed, 25 Sep 2002 11:58:10 -0700 (PDT)

Thanks for verifying this Raphael.

I think I've isolated the change that is causing the problem, but I still
don't know how to fix it. :-\

On 2002-09-05, Alan Modra applied a very large patch to gas which
included this change:

http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/gas/config/tc-avr.c.diff?r1=1.17&r2=1.18&cvsroot=src&f=h

I am still trying to get a grasp on why the change broke things.

In the mean time, binutils in cvs prior to sept 05 should work.

Ted Roth

On Wed, 25 Sep 2002, Raphael Assenat wrote:

:) On Wednesday 25 September 2002 12:08 pm, you wrote:
:)
:) I reinstalled the buggy version of binutils, and I got many
:) error messages like this one:
:)
:) objs/p1.o(.text+0x3ac): In function `_p1_expand_data':
:) : relocation truncated to fit: R_AVR_7_PCREL no symbol
:)
:) This error occurs many times in objs/p1.o. It occurs
:) at address 0x28, 0x42, 0x4c, 0x64, 0x74, 0x8C, 0x3AC 0x434.
:)
:)
:) after issuing an avr-objdump -S objs/p1.o | grep "3ac" I got:
:) 3ac:   00 f0           brcs    .+0             ; 0x3ae
:)
:) and at many other address:
:) 28:   04 f0           brlt    .+0             ; 0x2a
:) 42:   01 f0           breq    .+0             ; 0x44
:) 4c:   00 f0           brcs    .+0             ; 0x4e
:) 64:   00 f4           brcc    .+0             ; 0x66
:) 74:   01 f0           breq    .+0             ; 0x76
:) 8c:   04 f4           brge    .+0             ; 0x8e
:) 3ac:   00 f0           brcs    .+0             ; 0x3ae
:) 434:   00 f4           brcc    .+0             ; 0x436
:)
:)
:) > On Wed, 25 Sep 2002, Raphael Assenat wrote:
:) > :)
:) > : objs/p1.o(.text+0xb8):/home/raph/0Work/programming/ylib/programs/ATmega16
:) > :3_p1leds/p1.c:228: ) relocation truncated to fit: R_AVR_7_PCREL no symbol
:) > :) objs/p1.o(.text+0x37c): In function `_p1_expand_data':
:) >
:) > This is actually a bug in the assembler I think. Can you do me a favor and
:) > run p1.o through avr-objdump as such:
:) >
:) >   $ avr-objdump -S p1.o
:) >
:) > and see if the insn at 0x37c looks like this (or some brXX insn)?
:) >
:) >    brne .+0
:) Yes, there is a brXX instruction every time the error occurs.
:)
:) >
:) > Ted Roth
:)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]