Hi Jörg, mit dem aktuellen gcc trunk bekomm ich diesen Fehler in der testsuite, log anbei. Ein -Wl,-relax bzw. -mrelax hilft leider nicht. Ausserdem kommt der Fehler nur bei -flto; sieht also so aus, als ob das "Überlinken" der libgcc durch avr-libc nicht so funktioniert wie angedacht und durch LTO ausgehebelt wird: __addsf3 und __subsf3 sollten aus der avr-libc genommen werden, nicht aus der libgcc. Eigentlich sollte das ja auch ohne Relaxing funktionieren, oder? Von daher wundert mich das explizite RCALL in log.S. Ausserdem find ich Relaxing nicht so vertrausenserweckend wegen http://sourceware.org/PR12494
Ja, den Salat kenne ich leider, das habe ich auch schon gelegentlich gesehen. :-( Das ganze Zeug ist fehldesignt. Davon abgesehen, dass diese Funktionen ohnehin nicht in die avr-libc gehören, sondern in die libgcc direkt wandern sollten (was wieder all den bekannten Kram mit dem copyright assignment nach sich zieht), sie sollten sich wohl auch nicht drauf verlassen, dass sie inner-Bibliotheks-Sprünge immer mit einem RJMP/RCALL erreichen können. Stattdessen sollten sie einen "native jump" benutzen und dann auf die linker relaxations für die Optimierung vertrauen. U. U. könnte man mit einem beherzten -Wl,-u,__addsf3 erreichen, dass der Linker veranlasst wird, die libc.a-Implementierung bereits zu linken, bevor er in die Verlegenheit kommt, die aus der libgcc.a zu ziehen.
Was macht den eigentlich Relaxing? (neben falschen rcall/ret->rjmp Ersetzungen ;-)) [1] rjmp/rcall -> jmp/call falls nötig oder [2] jmp/call -> rjmp/rcall falls möglich [1] dürfte schon deshalb ausscheiden, weil sich Instruktionslängen vergrößern und dann u.U. br**-Offsets nicht mehr passen. [2] bringt hier offenbar nix. ergo [3] avr-libc darf nur rjmp/rcall nach extern ausgeben für Devices <= 8k Eine weitere Möglichkeit zur Umgehung bestimmter libgcc-Funktionen wäre die Funktionen in den gcc-optabs umzubenennen; das geht schmerzfrei im AVR-Teil. Dann wäre immer noch eine __addsf3 in libgcc, aber avr-gcc würde Aufrufe zu zB __avrlibc___addsf3 ausgeben, falls zB nicht -mno-avr-libc gesetzt ist. Man müsste sich nur über einen Präfix verständigen und welche Funktionen der ligcc dazugehören sollen. Auf diese Weise wäre der implementatorische Aufwand quasi 0: Neue Option in avr-gcc, Funktionen umbenennen und avr-libc klebt zusätzliche Labels an die Funktionen. Eine Verbesserung der Lokalität kann man doch auch über Sections erreichen, indem das Zeug zB nach .text.libgcc kommt.
Johann L. schrieb: > [2] jmp/call -> rjmp/rcall falls möglich Das hier (sowie das Auffüllen der trampolines bei devices > 128 KiB). > [3] avr-libc darf nur rjmp/rcall nach extern ausgeben für Devices <= 8k Ja. Der ganze Kram ist entstanden in der Annahme, dass die einzelnen Objektmodule der libc.a (bzw. libm.a) stets zusammenhängend gelinkt werden. Das hat lange Zeit auch ganz gut geklappt, aber allein durch den ganzen Kram mit den per-function sections ist das mittlerweile wohl komplett ad absurdum geführt worden. > Eine weitere Möglichkeit zur Umgehung bestimmter libgcc-Funktionen wäre > die Funktionen in den gcc-optabs umzubenennen; das geht schmerzfrei im > AVR-Teil. Ehrlich gesagt: lieber wäre es mir, wenn wir die Autoren der avr-libc- Funktionen davon überzeugen könnten, das wirklich dem GCC-Projekt zu spenden, einschließlich des ganzen sinnlosen Copyright-Assignment- Geraffels. > Dann wäre immer noch eine __addsf3 in libgcc, aber avr-gcc würde Aufrufe > zu zB __avrlibc___addsf3 ausgeben, falls zB nicht -mno-avr-libc gesetzt > ist. Hmm, klingt natürlich auch einladend …
Jörg Wunsch schrieb: > Johann L. schrieb: >> Eine weitere Möglichkeit zur Umgehung bestimmter libgcc-Funktionen wäre >> die Funktionen in den gcc-optabs umzubenennen; das geht schmerzfrei im >> AVR-Teil. > > Ehrlich gesagt: lieber wäre es mir, wenn wir die Autoren der avr-libc- > Funktionen davon überzeugen könnten, das wirklich dem GCC-Projekt > zu spenden, einschließlich des ganzen sinnlosen Copyright-Assignment- > Geraffels. Du glaubst doch nicht wirklich, daß jemand es schafft, die Horde von avr-libc Autoren aufzutreiben uns die was (egal wie relevant oder sinnig) unterschreiben zu lassen? >> Dann wäre immer noch eine __addsf3 in libgcc, aber avr-gcc würde Aufrufe >> zu zB __avrlibc___addsf3 ausgeben, falls zB nicht -mno-avr-libc gesetzt >> ist. > > Hmm, klingt natürlich auch einladend … IMO die einzig realistische Alternative. Pferdefuß ist, daß das eine bestimmte Version der avr-libc in gcc vorausetzt -- was aber mit dem PSTR-Fix ja auch schon de facto der Fall ist. Ein -mavr-libc wäre ja nur dann sinnvoll, wenn es standardmässig aktiviert ist.
Jörg Wunsch schrieb: > Johann L. schrieb: >> [3] avr-libc darf nur rjmp/rcall nach extern ausgeben für Devices <= 8k > > Ja. > > Der ganze Kram ist entstanden in der Annahme, dass die einzelnen > Objektmodule der libc.a (bzw. libm.a) stets zusammenhängend > gelinkt werden. Das hat lange Zeit auch ganz gut geklappt, aber > allein durch den ganzen Kram mit den per-function sections ist > das mittlerweile wohl komplett ad absurdum geführt worden. Versteh ich net. Das ist doch eher Sache, wie die avr-libc organisiert ist und generiert wird. Wenn man nur eine Funktion pro Object hat, stört's doch nicht, wenn die in der gleichen Section sind. Der Linker nimmt nur das, was er braucht; was wiederum durch die Granularität sichergestellt ist.
Johann L. schrieb: > Du glaubst doch nicht wirklich, daß jemand es schafft, die Horde von > avr-libc Autoren aufzutreiben uns die was (egal wie relevant oder > sinnig) unterschreiben zu lassen? So viele Autoren sind es nicht, die libgcc-relevante Teile geschrieben haben. Ganz davon abgesehen, hat Eric es vor ein paar Jahren geschafft, die Änderung der Lizenzklauseln auf die jetzige einheitliche Form von allen Autoren absegnen zu lassen. Johann L. schrieb: > Wenn man nur eine Funktion pro Object hat, stört's doch nicht, > wenn die in der gleichen Section sind. Der Linker nimmt nur das, was er > braucht; was wiederum durch die Granularität sichergestellt ist. Die Hilfsfunktionen werden teilweise von mehr als einer anderen Funktion gerufen. Naja, meiner Meinung nach könnte man den ganzen function-sections- Kram einsparen. Die Leute sollen bitte nur den Sourcecode schreiben und compilieren, den sie auch wirklich verwenden wollen. ;-) Das mit dem -gc-sections ist doch eine Einladung dazu, gar nicht mehr zu wissen, was man da je zusammengezimmert hat, und unbenutzten Code über Jahre in einem Projekt mitzuschleppen. Egal, das ist jetzt halt so, daran ändert sich nun nichts mehr. Ich stimme dir zu, dass die RJMP/RCALLs da drin raus müssen. Das alles sollte man wohl besser auf der avr-libc-Liste diskutieren.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.