R_AVR_13_PCREL against symbol

[Werner (Gast)]

Hallo,

ich habe wie im Betreff geschrieben ein Problem beim Linken. Die 
Bibliothek libm.a wird im Linker am Ende mitgelinkt. Nichtsdestrotz 
bekomme ich immer den Fehler. Verschiedene Einstellungen am Compiler 
haben mich nicht weitegebracht.

Unten habe ich die gesamte Ausgabe eingefügt. Ich weiss nicht woran der 
Fehler liegen könnte.

Wäre dankbar wenn mir jemand einen Tipp geben könnte.

Grüße
Werner

avr-gcc -Wall -Os -lm -mmcu=atmega162 -DF_CPU=11059200UL -MMD -MP -MF"ucossource/os_core.d" -MT"ucossource/os_core.d" -c -o "ucossource/os_core.o" "../ucossource/os_core.c"

avr-gcc -Wall -Os -lm -mmcu=atmega162 -DF_CPU=11059200UL -MMD -MP -MF"ucossource/os_flag.d" -MT"ucossource/os_flag.d" -c -o "ucossource/os_flag.o" "../ucossource/os_flag.c"

avr-gcc -Wall -Os -lm -mmcu=atmega162 -DF_CPU=11059200UL -MMD -MP -MF"ucossource/os_mbox.d" -MT"ucossource/os_mbox.d" -c -o "ucossource/os_mbox.o" "../ucossource/os_mbox.c"

avr-gcc -Wall -Os -lm -mmcu=atmega162 -DF_CPU=11059200UL -MMD -MP -MF"ucossource/os_mem.d" -MT"ucossource/os_mem.d" -c -o "ucossource/os_mem.o" "../ucossource/os_mem.c"

avr-gcc -Wall -Os -lm -mmcu=atmega162 -DF_CPU=11059200UL -MMD -MP -MF"ucossource/os_mutex.d" -MT"ucossource/os_mutex.d" -c -o "ucossource/os_mutex.o" "../ucossource/os_mutex.c"

avr-gcc -Wall -Os -lm -mmcu=atmega162 -DF_CPU=11059200UL -MMD -MP -MF"ucossource/os_q.d" -MT"ucossource/os_q.d" -c -o "ucossource/os_q.o" "../ucossource/os_q.c"

avr-gcc -Wall -Os -lm -mmcu=atmega162 -DF_CPU=11059200UL -MMD -MP -MF"ucossource/os_sem.d" -MT"ucossource/os_sem.d" -c -o "ucossource/os_sem.o" "../ucossource/os_sem.c"

avr-gcc -Wall -Os -lm -mmcu=atmega162 -DF_CPU=11059200UL -MMD -MP -MF"ucossource/os_task.d" -MT"ucossource/os_task.d" -c -o "ucossource/os_task.o" "../ucossource/os_task.c"

avr-gcc -Wall -Os -lm -mmcu=atmega162 -DF_CPU=11059200UL -MMD -MP -MF"ucossource/os_time.d" -MT"ucossource/os_time.d" -c -o "ucossource/os_time.o" "../ucossource/os_time.c"
 
avr-gcc -Wall -Os -lm -mmcu=atmega162 -DF_CPU=11059200UL -MMD -MP -MF"MTuart.d" -MT"MTuart.d" -c -o "MTuart.o" "../MTuart.c"

avr-gcc -Wall -Os -lm -mmcu=atmega162 -DF_CPU=11059200UL -MMD -MP -MF"Main.d" -MT"Main.d" -c -o "Main.o" "../Main.c"
../Main.c:264: warning: 'AppTask3' defined but not used
../Main.c:280: warning: 'AppTask4' defined but not used
 

avr-gcc -x assembler-with-cpp -mmcu=atmega162 -MMD -MP -MF"os_cpu_a.d" -MT"os_cpu_a.d" -c -o "os_cpu_a.o" "../os_cpu_a.S"
 
avr-gcc -Wall -Os -lm -mmcu=atmega162 -DF_CPU=11059200UL -MMD -MP -MF"os_cpu_c.d" -MT"os_cpu_c.d" -c -o "os_cpu_c.o" "../os_cpu_c.c"

avr-gcc -Wl,-Map,AVRCompilerTest.map -lm -mmcu=atmega162 -o "AVRCompilerTest.elf"  ./ucossource/os_core.o ./ucossource/os_flag.o ./ucossource/os_mbox.o ./ucossource/os_mem.o ./ucossource/os_mutex.o ./ucossource/os_q.o ./ucossource/os_sem.o ./ucossource/os_task.o ./ucossource/os_time.o  ./MTuart.o ./Main.o ./os_cpu_a.o ./os_cpu_c.o   -lm
./os_cpu_a.o: In function `_not_first_int':
(.text+0x1ea): relocation truncated to fit: R_AVR_13_PCREL against symbol `OSTimeTick' defined in .text section in ./ucossource/os_core.o
./os_cpu_a.o: In function `_not_first_int':
(.text+0x1ee): relocation truncated to fit: R_AVR_13_PCREL against symbol `OSIntExit' defined in .text section in ./ucossource/os_core.o

[Yalu X. (yalu) (Moderator)]

Offensichtlich werden irgendwo OSTimeTick und OSIntExit PC-relativ über
eine zu große Distanz angesprungen. Schau mal nach, ob du in os_cpu_a.S
folgende Zeilen findest:

  rcall OSTimeTick

und

  rcall OSIntExit

Wenn ja, ersetze rcall jeweils durch call.

Alternativ kannst du im Linker-Befehl die Argumente anders anordnen, so
dass ./os_cpu_a.o näher bei ./ucossource/os_core.o steht.

[Johann L. (gjlayde)]

Mach das -lm ans Ende der Optionen des (Linker-)Aufrufs.

Wenn das nicht hilft ist's wahrscheinlich
- Falsches (Inline) Assembler, s.o
- http://savannah.nongnu.org/bugs/?33698
- http://sourceware.org/PR13410

[Jörg W. (dl8dtl) (Moderator)]

Johann L. schrieb:
> Mach das -lm ans Ende der Optionen des (Linker-)Aufrufs.

Hat er schon.  Die Beschwerde richtet sich ja auch überhaupt nicht
gegen irgendwas aus libm.a oder libgcc.a.

Ich vermute, dass Yalu Recht hat und os_cpu_a.S Mist macht.

[Werner (Gast)]

Danke Euch allen Dreien.

Yalu X. schrieb:
> rcall OSTimeTick
>
> und
>   rcall OSIntExit
>
> Wenn ja, ersetze rcall jeweils durch call.


Exakt das war es. Wäre ich nie selber drauf gekommen. Mir ist zwar schon 
aufgefallen, dass sich die Fehlermeldungen auf die Assembler-Datei 
bezogen aber auf den rcall bin ich nicht gekommen. Ich habe da schon 
seit Tagen gesucht und Google hat mir auch nicht weitergeholfen.

Nochmals vielen Dank

[Johann L. (gjlayde)]

Werner schrieb:
> Danke Euch allen Dreien.
>
> Yalu X. schrieb:
>>   rcall OSTimeTick
>> und
>>   rcall OSIntExit
>>
>> Wenn ja, ersetze rcall jeweils durch call.
>
> Exakt das war es. Wäre ich nie selber drauf gekommen.

Wenn die Quelle für unterschiedliche Devices zum Einsatz kommt kann man 
auch parametrisieren, zB per

#if defined (__AVR_HAVE_JMP_CALL__)
#define XCALL call
#define XJMP  jmp
#else
#define XCALL rcall
#define XJMP  rjmp
#endif

und XCALL bzw. XJMP verwenden.  Um die kurze Variante zu erzeugen falls 
verfügbar, gibt man -mrelax oder -Wl,--relax an.

Jörg Wunsch schrieb:
> Johann L. schrieb:
>> Mach das -lm ans Ende der Optionen des (Linker-)Aufrufs.
>
> Hat er schon.

Ah ja, jetzt seh ich's.

> Die Beschwerde richtet sich ja auch überhaupt nicht
> gegen irgendwas aus libm.a oder libgcc.a.

A propos, wird #33698 irdendwann mal gefixt?

[Jörg W. (dl8dtl) (Moderator)]

Johann L. schrieb:
> A propos, wird #33698 irdendwann mal gefixt?

Ja, wie ich schon mal schrieb, typischerweise setze ich mich ein
paar Abende lang hin und arbeite Bugfixes ein während der Vorbereitung
für ein neues Release.  Ich gehe mal davon aus, dass das noch vor
den Sommerferien sein wird, aber vorher möchte ich erstmal AVRDUDE
6.0 freigeben.

[Johann L. (gjlayde)]

Jörg Wunsch schrieb:

> typischerweise setze ich mich ein paar Abende lang hin und arbeite
> Bugfixes ein während der Vorbereitung für ein neues Release.

hmm, ok

Insbesondere #35407 ist womöglich doch etwas mehr Aufwand, insbesondere 
die erforderlichen Erweiterungen im Buildsystem gegen verschiedene 
gcc-Versionen zu testen. Wenn ich recht sehe wird momentan noch 
-mtiny-stack als multilib-Option verwendet; korrekt wäre aber -msp8.

Wenn die multilib-Layouts von Lib und gcc nicht zusammenpassen, dann 
kann man mit einer Release nicht viel anfangen -- egal wieviel andere 
Bugs diese behebt :-/

[Jörg W. (dl8dtl) (Moderator)]

Johann L. schrieb:
> Wenn die multilib-Layouts von Lib und gcc nicht zusammenpassen, dann
> kann man mit einer Release nicht viel anfangen -- egal wieviel andere
> Bugs diese behebt :-/

Ja, danke für die Vorwarnung, ich werde mir dafür entsprechend mehr
Zeit gedanklich einplanen.  Einen SVN-trunk-GCC habe ich ja typisch
ohnehin daliegen, gegen den ich das testen kann.

[Johann L. (gjlayde)]

Jörg Wunsch schrieb:
> Johann L. schrieb:
>> Wenn die multilib-Layouts von Lib und gcc nicht zusammenpassen, dann
>> kann man mit einer Release nicht viel anfangen -- egal wieviel andere
>> Bugs diese behebt :-/
>
> Ja, danke für die Vorwarnung, ich werde mir dafür entsprechend mehr
> Zeit gedanklich einplanen.

und damit's nicht allzu langweilig wird: -msp8 ist erst ab 4.7.1 
bekannt.
In 4.7.0 — und nur dort — fungiert -mtiny-stack als multilib-Option, 
siehe PR51345 und PR52741.