ld status -1 - werde aus Fehlermeldung nicht schlau

Die Objektmodule, für die der Linker das beanstandet, wurden laut
diesem Build-Log soeben nicht neu gebaut. Bist du dir sicher,
dass für deren Compilieren auch -mmcu=atmega32 gesetzt war?

Hallo Jörg,
danke, daß Du Dir diesen Wust angesehen hast. Ich bin mir zumindest sehr 
sicher, daß das Objectfile noch nie für ein andere Target als den 
ATmega32 erzeugt worden ist. Aber Du hast Recht: Ich hätte besser das 
Log eines kompletten Rebuilds gezeigt.

Ich konnte den Fehler jetzt auf ein paar snprintf auf static 
uint8_t-Variablen in der Datei "edm.c" eingrenzen (Sprich: sind die 
auskommentiert, geht alles sichtbare so, wie ich es erwarte). Mir ist 
die Ursache noch etwas rätselhaft, aber ein Ansatz zur Behebung ist 
jetzt da.

Viele Grüße
Nicolas

Beim Relozieren kann ein relativer Sprung nicht aufgelöst werden, weil 
da, wo die Relokation eingetragen werden soll, nur ein 13-Bit-Feld zu 
Verfügung steht, aber die Distanz größer als 13 Bit ist.

Siehe http://www.technovelty.org/c/relocation-truncated-to-fit-wtf.html

Hallo Konrad,
Du meinst die Objekte liegen weiter als 8kB auseinander und der Linker 
schafft das nicht mehr, die Teile sinnvoll anzuordnen?

Die Größenordnung von 8kB für das Hex-File könnte tatsächlich so langsam 
erreicht werden (die genaue Größe kann ich momentan nicht prüfen) - ist 
das eine harte Grenze für irgendetwas und gibt es 
"Programmierrichtlinien über 8kB"?

Viele Grüße
Nicolas

P.S.: Nach dem Artikel scheint es ein Problem der Buildoptionen zu sein. 
Vielleicht '-mshort-calls'? Also wird der zweite Schritt die Suche in 
die Richtung sein.

OK, bin durch Zufall gerade drauf gestoßen:

http://www.nongnu.org/avr-libc/user-manual/using_tools.html

> -mshort-calls
>
> Use rjmp/rcall (limited range) on >8K devices. On avr2 and avr4
> architectures (less than 8 KB or flash memory), this is always the case.
> On avr3 and avr5 architectures, calls and jumps to targets outside the
> current function will by default use jmp/call instructions that can cover
> the entire address range, but that require more flash ROM and execution
> time.

d.h. die Build-Optionen passen einfach nicht mehr, wenn der Flash >8kB 
benötigt wird. Komisch, daß Atmel Studio die Defaultoptionen so 
"gefährlich" setzt.

Bleibt die Frage: Kann ich den Build so ändern, daß kurze Sprünge immer 
reichen, z.B. große Lookuptables irgendwie in die Näher der sie 
aufrufenden Funktionen rücken?

Viele Grüße
Nicolas

Nicolas S. schrieb:
> -mshort-calls >

Ach du Sch***.  Die war mir entgangen.

Diese Option hätte nie im GCC implementiert werden dürfen, und erst
recht nicht im AVR Studio den Nutzern zugänglich gemacht werden.

Auf einem Controller mit mehr als 8 KiB Flash müssen by default lange
Aufrufe benutzt werden (CALL statt RCALL).  Wenn überhaupt, kann
man dem Linker (mit -mrelax) es überlassen, daraus wieder kurze zu
machen, denn der weiß, wo die einzelnen Funktionen liegen. Andererseits
ist der Performancegewinn minimal, kann man also auch sein lassen.

lookup tables liegen ohnehin direkt bei den Funktionen, die sie
benötigen, aber das spielt keine große Rolle.

Nicolas S. schrieb:
> Komisch, daß Atmel Studio die Defaultoptionen so
> "gefährlich" setzt.

Macht es nicht. Das hast du selber irgendwann mal 
angeklickt/eingetragen.

Mag sein, daß es durch die Konvertierung von AVR-Studio 4 auf 
Atmel-Studio 6 (ich bin gerade dabei, ein 2 Jahre liegengebliebenes 
Projekt fortzuführen) irgendwie hineingekommen ist. Normalerweise halte 
ich mich mit dem Auswählen von Optionen, deren Zweck mir nicht völlig 
klar ist, sehr zurück und gehe davon aus, daß die Standardoptionen 
durchaus einen Sinn haben.

Naja, ganz ausschließen kann man es nie, in mehreren Jahren ein Häkchen 
womöglich angeklickt zu haben.

Also ist es vielleicht eine gute Idee, das Projekt unter AtmelStudio 6 
noch einmal neu aufzusetzen - wer weiß welche Settings sonst noch 
implizit übernommen wurden aus den Zeiten, wo es mal unter AVR Studio 4 
auf einem ATmega48 aufgesetzt wurde, und womöglich erst mit zunehmender 
Codegröße zum Vorschein kommen. Allein daß der Projektname, der an allen 
möglichen Stellen als Dateiname auftaucht nun wirklich überhaupt nichts 
mehr mit dem gegenwärtigen Entwicklungsziel zu tun hat nervt schon ein 
bischen.

Vielen Dank für die Unterstützung
Nicolas

Jörg Wunsch schrieb:
> Nicolas S. schrieb:
>> -mshort-calls
>
> Diese Option hätte nie im GCC implementiert werden dürfen, [...]

Ab 4.8 ist wieder aus dem Compiler entfernt :-)

> On AVR, support has been removed for the command-line option
> -mshort-calls deprecated in GCC 4.7.

http://gcc.gnu.org/gcc-4.8/changes.html

Johann L. schrieb:
> Ab 4.8 ist wieder aus dem Compiler entfernt :-)

Verbindlichsten Dank! ;-)