R_AVR_13_PCREL against symbol

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:

1

  rcall OSTimeTick

und

1

  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.

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

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 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

1

#if defined (__AVR_HAVE_JMP_CALL__)

2

#define XCALL call

3

#define XJMP  jmp

4

#else

5

#define XCALL rcall

6

#define XJMP  rjmp

7

#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?

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.

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 :-/

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.

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.