www.mikrocontroller.net

Forum: Compiler & IDEs avr-gcc und avr-libc: wie passt das zusammen?


Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, ich würd gerne besser verstehen, wie avr-gcc und avr-libc 
zusammenpassen, insbesondere auch, um

http://gcc.gnu.org/PR28718
http://gcc.gnu.org/PR29524

besser zu verstehen. Die englischen Erklärungen sind mir da auch nicht 
immer klar.

Autor: pedro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
avr-gcc --> compiler

avr-libc --> Bibliotheken mit allerlei funktionen und defines, angepasst 
an avr-mikrokontroller

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir ist nicht klar, warum
volatile float a;
volatile int i;

int main ()
{
    a = i;
    return 0;
}

gegen __clz_tab[] linkt
> avr-g++ -lm -mmcu=atmega1280 ...

avr-gcc 4.3.3

Autor: Andreas B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
__clz_tab wird wohl von einer internen Funktion zur Konvertierung von 
int zu float (die Zeile "a = i") gebraucht.

Autor: pedro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"The array __clz_tab is used in a macro, count_leading_zeros, which is 
called in the function __clzSI2 in libgcc2.c, which (AFAICT) gets 
compiled to the function __clzsi2 and aggregated in libgcc. The __clzsi2 
function is called from the function clzusi() (in fp-bit.c) which is 
also included in libgcc. Thecl usi() function is called from 
si_to_float() and usi_to_float() (also in fp-bit.c and included in 
libgcc). AFAICT, these two functions are used to convert an int or 
unsigned int to float."

mit anderen worten: wenn du deinen int auf einen float castest, linkt 
gcc auf __clz_tab.

umgehen mit:

"I just found out what's causing this confusion. If you compile your 
program
like this:

avr-gcc -Os -mmcu=atmega168 -lm main.c -o main.elf

__clz_tab gets included. But if you compile like this:

avr-gcc -Os -mmcu=atmega168 main.c -lm -o main.elf

it doesn't!!!

So, the order you pass -lm matters to the final outcome.

Tested with gcc 4.2.2, libc 1.4.6 and libc 1.6.1."


für dich heisst das makefile anpassen, mit der richtigen reihenfolge der 
parameter sollte laut dem bug-forum __clz_tab nicht mehr verwendet 
werden.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pedro schrieb:
> "The array __clz_tab is used in a macro, count_leading_zeros, which is
> called in the function __clzSI2 in libgcc2.c, which (AFAICT) gets
> compiled to the function __clzsi2 and aggregated in libgcc. The __clzsi2
> function is called from the function clzusi() (in fp-bit.c) which is
> also included in libgcc. Thecl usi() function is called from
> si_to_float() and usi_to_float() (also in fp-bit.c and included in
> libgcc). AFAICT, these two functions are used to convert an int or
> unsigned int to float."
>
> mit anderen worten: wenn du deinen int auf einen float castest, linkt
> gcc auf __clz_tab.

__clz_tab wird in count_leading_zeros zwar verwendet (longlong.h), aber 
für den Fall W_TYPE_SIZE <= 32 nicht referenziert, da libgcc mit -O 
übersetzt wird. Eine Referenz findet sich im erzeugten elf zudem nicht.

> avr-gcc -Os -mmcu=atmega168 -lm main.c -o main.elf

oben wird avr-g++ verwendet.

> für dich heisst das makefile anpassen, mit der richtigen reihenfolge der

welches Makefile? Die einzige Option wäre t-avr anzupassen oder was an 
den specs zu drehen.

Autor: pedro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> __clz_tab wird in count_leading_zeros zwar verwendet (longlong.h), aber
> für den Fall W_TYPE_SIZE <= 32 nicht referenziert, da libgcc mit -O
> übersetzt wird. Eine Referenz findet sich im erzeugten elf zudem nicht.
>

buh, kann dir nicht genau sagen, was alles im elf-file steht, sollte 
aber bereits maschinensprache mit debug-infos sein. k.a.

>
> oben wird avr-g++ verwendet.
>

soweit ich weis gibts keinen unterschied zwischen avr-gcc und avr-g++ 
(sollten beide gehen). beides steht für c++, gcc kann auch c++, nicht 
nur c ;-)

>
> welches Makefile? Die einzige Option wäre t-avr anzupassen oder was an
> den specs zu drehen.

verwendest du avr-studio? dieses generiert das makefile selber. wenn du 
dein modiviziertes makefile verwenden willst, kannst du ein neues 
projekt machen und dein makefile hinzufügen (statt dieses selbst 
generieren zu lassen)

Autor: pedro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
doppelpost: das makefile sollte im projektorder zu finden sein, mit 
einigermassen gutem texteditor bearbeitbar

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier ein einfacherer Testfall ohne floats:
volatile int i;

int main ()
{
    return __builtin_clz (i);
}

Auch avr-gcc linkt gegen __clz_tab

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pedro schrieb:
> doppelpost: das makefile sollte im projektorder

Es gibt kein Projekt und auch kein Makefile. Es geht nicht darum, in 
einem Projekt einen Workaround zu finden, sondern ich will verstehen, 
wie es dazu kommt, um das zu ändern. Dazu will ich das Zusammenspiel von 
avr-gcc und avr-libc und libgcc besser verstehen und wie die specs da 
eingreifen, d.h. ob es ein Fehler in den specs ist (glaub ich nicht), 
eher in der Konfiguration der libgcc, daß da für avr was fehlt.

Der Vorschlag am Ende von PR29524 (inline assembler in longlong.h) 
dürfte also nix bringen, ausser im 64-Bit Fall und unter der Annahme, 
daß nur gegen verwendete Symbole gelinkt wird.

Autor: pedro (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sorry, bin am ende. ich bin auf work-arounds trainiert :-)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Hier ein einfacherer Testfall ohne floats:

Der holt sich __clzhi2 aus der libgcc.a, und diese referenziert
__clz_tab:
_clzhi2.o:     file format elf32-avr


Disassembly of section .text:

00000000 <__clzhi2>:
   0:   fc 01           movw    r30, r24
   2:   8f 3f           cpi     r24, 0xFF       ; 255
   4:   91 05           cpc     r25, r1
   6:   01 f0           breq    .+0             ; 0x8 <__clzhi2+0x8>
                        6: R_AVR_7_PCREL        .text+0xa
   8:   00 f4           brcc    .+0             ; 0xa <__clzhi2+0xa>
                        8: R_AVR_7_PCREL        .text+0x1c
   a:   80 31           cpi     r24, 0x10       ; 16
   c:   91 05           cpc     r25, r1
   e:   00 f0           brcs    .+0             ; 0x10 <__clzhi2+0x10>
                        e: R_AVR_7_PCREL        .text+0x16
  10:   84 e0           ldi     r24, 0x04       ; 4
  12:   90 e0           ldi     r25, 0x00       ; 0
...
  3e:   02 f4           brpl    .+0             ; 0x40 <__clzhi2+0x40>
                        3e: R_AVR_7_PCREL       .text+0x38
  40:   e0 50           subi    r30, 0x00       ; 0
                        40: R_AVR_LO8_LDI_NEG   __clz_tab
  42:   f0 40           sbci    r31, 0x00       ; 0
                        42: R_AVR_HI8_LDI_NEG   __clz_tab
  44:   80 81           ld      r24, Z
  46:   28 1b           sub     r18, r24
  48:   31 09           sbc     r19, r1
  4a:   c9 01           movw    r24, r18
  4c:   08 95           ret

Mit der avr-libc hat das alles nicht viel zu tun, wenn man davon
absieht, dass diese einige der Funktionen der libgcc.a überschreibt
(argl, ja, ich weiß), sodass man die Referenz auf __clz_tab für
den Fall der Gleitkommakonvertierung los wird, indem man (korrekt)
gegen -lm linkt.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Johann L. schrieb:
>> Hier ein einfacherer Testfall ohne floats:
>
> Der holt sich __clzhi2 aus der libgcc.a, und diese referenziert
> __clz_tab:

ARGL, die wichtige Stelle hab ich übersehen... Das heisst andererseits, 
daß nur die longlong.h angepasst werden muss (bzw. angepasst werden 
müsste), um __clz_tab loszuwerden, auch wenn man nicht gegen die libm 
linkt und auch für C++.

> Mit der avr-libc hat das alles nicht viel zu tun, wenn man davon
> absieht, dass diese einige der Funktionen der libgcc.a überschreibt
> (argl, ja, ich weiß), sodass man die Referenz auf __clz_tab für
> den Fall der Gleitkommakonvertierung los wird, indem man (korrekt)
> gegen -lm linkt.

Ich versteh nicht wie das Überschreiben funktioniert... wieso gibt das 
keine Linkerfehler, wenn Symbole doppelt sind? Oder sind die weak?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:

> Ich versteh nicht wie das Überschreiben funktioniert... wieso gibt das
> keine Linkerfehler, wenn Symbole doppelt sind?

Weil aus den Bibliotheken nur die wirklich benötigten Sachen geholt
werden, d. h. Symbole, die zum Zeitpunkt, da der Linker die jeweilige
Bibliothek betrachtet "global undefined" sind.  In deinem ersten
Beispiel (mit den floats) wäre das die Funktion __floatsisf, deren
Aufruf vom Compiler (mit der Absicht, diese aus der libgcc.a nehmen
zu lassen) in den Code eingebaut wird.  Wenn man nicht gegen die
libm.a linkt (bzw. die Linkerreihenfolge nicht stimmt, wie in deinem
Beispiel — zu dem Zeitpunkt, da das -lm verarbeitet wird, existiert
noch gar keine undefinierte Referenz zu __floatsisf, da noch kein
Stück User-Objektdatei dem Linker übergeben worden ist), dann würde
letztlich diese Funktion auch tatsächlich aus der libgcc.a geholt,
und die dort befindliche wiederum referenziert dann die leidige
__clz_tab, die danach ebenfalls aus libgcc.a reingezogen wird.

Setzt man dagegen an das Ende (!) des Linkeraufrufs ein -lm, dann
wird libm.a vor der libgcc.a abgegrast.  Dort findet sich eine
Implementierung für __flaotsisf (die sich natürlich von der in der
libgcc.a grundlegend unterscheidet und daher kein __clz_tab braucht),
der entsprechende Modul wird geladen.  Der parallele Modul in der
libgcc.a wird danach nicht mehr angeguckt, weil zu ihm nun keine
ungelöste Referenz mehr existiert.

Ja, das ist alles suboptimal.  Um das zu beseitigen, müssten die
Autoren aller Funktionen in der avr-libc, die Module in der libgcc.a
überschreiben, diese Implementierungen mitsamt einem entsprechenden
Patch für die Infrastruktur (damit die Implementierung auch statt
der default-Implementierung genutzt wird), sowie mitsamt dem
vermaledeiten copyright assignment bei GCC einkippen und anschließend
jemanden nerven, dass er diesen ihren Patch bitteschön doch auch
endlich mal einbauen möge.  Das ist zeit- und nervenaufwändig, ohne
dass es am Ende auch nur ein Stückchen wirkliche Verbesserung gegenüber
dem derzeitigen Zustand bringen würde (es wäre eben nur "sauberer" so).
Ach ja, neu (nämlich unter GPL) lizensieren müssten die Autoren diesen
ihren Code natürlich auch noch.  Ist vermutlich nicht das wirkliche
Problem hier, aber das blöde copyright assignment ist in meinen Augen
der wesentliche Hemmschuh, wobei die Prozedur, die man befolgen muss,
um bei GCC wirklich einen Patch auch durchzuboxen, gleich danach
kommt.  Dagegen ist die Bearbeitung der Patches in der avr-libc ja
schon fast goldig (auch, wenn wir dort teilweise ziemlich hinterher
hängen aufgrund fehlender man power).

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Johann L. schrieb:
>
>> Ich versteh nicht wie das Überschreiben funktioniert... wieso gibt das
>> keine Linkerfehler, wenn Symbole doppelt sind?
>
> Weil aus den Bibliotheken nur die wirklich benötigten Sachen geholt
> werden, d. h. Symbole, die zum Zeitpunkt, da der Linker die jeweilige
> Bibliothek betrachtet "global undefined" sind.  In deinem ersten
> Beispiel (mit den floats) wäre das die Funktion __floatsisf, deren
> Aufruf vom Compiler (mit der Absicht, diese aus der libgcc.a nehmen
> zu lassen) in den Code eingebaut wird.  Wenn man nicht gegen die
> libm.a linkt (bzw. die Linkerreihenfolge nicht stimmt, wie in deinem
> Beispiel — zu dem Zeitpunkt, da das -lm verarbeitet wird, existiert
> noch gar keine undefinierte Referenz zu __floatsisf, da noch kein
> Stück User-Objektdatei dem Linker übergeben worden ist), dann würde
> letztlich diese Funktion auch tatsächlich aus der libgcc.a geholt,
> und die dort befindliche wiederum referenziert dann die leidige
> __clz_tab, die danach ebenfalls aus libgcc.a reingezogen wird.

Ok, d.h. "PR28718: Call to -lgcc added prior to user libraries" ist also 
bereits Geschichten. Wurde mir aus der dortigen Diskussion nicht ganz 
klar.

Wenn das -lm an der falschen Stelle steht, würd begingroup/endgroup in 
den specs helfen?

> Ja, das ist alles suboptimal.  Um das zu beseitigen, müssten die
> Autoren aller Funktionen in der avr-libc, die Module in der libgcc.a
> überschreiben,

Der Vorteil wäre, daß das die Registerlast reduzieren würde, 
entsprechende Vorkehrungen in avr-gcc vorausgesetzt, ganz ähnlich wie es 
für divmod* gemacht ist. Zumindest dann, wenn die Implementierung in asm 
vorliegt, was wohl für viele Funktionen der Fall ist.

Andererseits: Ist das alles IEEE? Ohne das braucht mit übereine 
Integration in gcc überhaupt nicht nachzudenken -- von dem 
administrativen/lizenztechnischen Aufwand mal abgesehen.

Die optabs bieten die Möglichkeit, libfuncs unter anderem Namen erzeugen 
zu lassen, um gcc an eine andere ABI anzupassen. Mit einem 
entsprechenden Compilerschalter würde dann kein __floatsisf auftauchen, 
sondern zB __my_int2float. Allerdings müsste dazu eine option gesetzt 
werden, weil das standardmässig zu aktivieren keine gute Idee wäre und 
verständlicherweise auch nicht durchginge auf gcc-Seite.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:

> Ok, d.h. "PR28718: Call to -lgcc added prior to user libraries" ist also
> bereits Geschichten.

Nein, ich glaube nicht.  Dort geht es um C++ und um ein Setup, das
keine libc++.a (oder wie auch immer die gerade heißt) besitzt.
Bei einem solchen wird (wurde?) dann idiotischerweise ein Aufruf
an libgcc.a statt des Aufrufs an libc++.a eingebaut, und zwar
dieses vor dem ersten Einbinden der libm.a, die vom Nutzer mittels
-lm beantragt war.

> Wenn das -lm an der falschen Stelle steht, würd begingroup/endgroup in
> den specs helfen?

Nein, glaube ich nicht.  Man muss einfach dran denken, wie der Linker
arbeitet, und dass Bibliotheken halt hinten auf die Kommandozeile
gehören, nach allen C-Dateien (bzw. den Objekten, die daraus
compiliert worden sind).

> Andererseits: Ist das alles IEEE?

IEEE-854 meinst du?  Ja, natürlich nur single precision (aber das
ist ja beim Compiler bereits der Fall).  Es gibt in der avr-libc
ja eine ziemlich umfängliche Testsuite, die maßgeblich von Dmitry
Xmelkov befüttert worden ist.  Ich glaube, irgendeiner der nur
marginal interessanten NaN oder denormal oder so Testcases liefert
gerade einen Fehler, aber ansonsten sieht das alles recht gut aus.

> Die optabs bieten die Möglichkeit, libfuncs unter anderem Namen erzeugen
> zu lassen, um gcc an eine andere ABI anzupassen. Mit einem
> entsprechenden Compilerschalter würde dann kein __floatsisf auftauchen,
> sondern zB __my_int2float.

Hmm, naja, einfacher (und ohnehin sinnvoll) wäre es wohl, endlich
mal alle Funktionen der libm.a gleich noch mit in die libc.a zu
kippen.  Müsste ich nur endlich mal tun...  Es gibt keinen sinnvollen
Grund mehr für diese Trennung, die letztlich aus der Zeit einer PDP-11
stammt.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Johann L. schrieb:
>
>> Ok, d.h. "PR28718: Call to -lgcc added prior to user libraries" ist also
>> bereits Geschichten.
>
> Nein, ich glaube nicht.  Dort geht es um C++ und um ein Setup, das
> keine libc++.a (oder wie auch immer die gerade heißt) besitzt.
> Bei einem solchen wird (wurde?) dann idiotischerweise ein Aufruf
> an libgcc.a statt des Aufrufs an libc++.a eingebaut, und zwar
> dieses vor dem ersten Einbinden der libm.a, die vom Nutzer mittels
> -lm beantragt war.

hmmm. ist das gcc-Automatismus oder hilft ein eigenes specfile, also 
-dumpspecs und das verändert wieder reinfüttern. specs sind echt der 
Horror...

>> Andererseits: Ist das alles IEEE?
>
> IEEE-854 meinst du?  Ja, natürlich nur single precision (aber das
> ist ja beim Compiler bereits der Fall).  Es gibt in der avr-libc
> ja eine ziemlich umfängliche Testsuite, die maßgeblich von Dmitry
> Xmelkov befüttert worden ist.  Ich glaube, irgendeiner der nur
> marginal interessanten NaN oder denormal oder so Testcases liefert
> gerade einen Fehler, aber ansonsten sieht das alles recht gut aus.

Oh, ich hätte ja getippt daß da aus Optimierungsgründen keine NANs, INFs 
oder Denormals abgehandelt werden ;o)

Wie sieht's mit fixed-point aus, sind die in 854? oder sind das nur die 
decimal-floats. gcc kann inzwischen ja fixedpoint nativ unterstützen und 
die Community ist ganz heiß drauf. Irgendwo gab's wohl mal ein download 
wo das eingebaut war.

>> Die optabs bieten die Möglichkeit, libfuncs unter anderem Namen erzeugen
>> zu lassen, um gcc an eine andere ABI anzupassen. Mit einem
>> entsprechenden Compilerschalter würde dann kein __floatsisf auftauchen,
>> sondern zB __my_int2float.
>
> Hmm, naja, einfacher (und ohnehin sinnvoll) wäre es wohl, endlich
> mal alle Funktionen der libm.a gleich noch mit in die libc.a zu
> kippen.  Müsste ich nur endlich mal tun...

Ok.

Würde eigentlich ein in-tree-build der avr-libc in gcc funktionieren? 
Ist ganz nett beim Generieren das und mach ich mit der newlib so. D.h. 
parallel zu dem gmp/mpfr/mpc-Zeugs nen Softlink newlib->avr-libc und 
dann configure/make/install und alles geht in einem Rutsch.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:

(libstdc++ vs. libgcc)

> hmmm. ist das gcc-Automatismus oder hilft ein eigenes specfile, also
> -dumpspecs und das verändert wieder reinfüttern. specs sind echt der
> Horror...

Meiner Erinnerung nach (ist schon paar Jahre her) ist das ein
GCC-Automatismus.  Sie wollen offenbar an dieser Stelle einen
Aufruf einer Bibliothek einbauen beim Linken eines C++-Jobs, und
wenn die Konfiguration keine libstdc++ hat (so heißt sie wohl,
habe ich mich jetzt erinnert), dann fallen sie zurück auf eine
libgcc.  Das ist natürlich an dieser Stelle nicht wirklich
sinnvoll, aber außer der AVR-Gemeinde wird darüber niemand sonst
stolpern: der Aufruf der libgcc ist nur für AVR tödlich, weil dann
das Prinzip "wir liefern in der libm ein paar overrides für die
libgcc, weil wir sie besser optimiert haben" nicht mehr funktioniert.

Den Bugreport habe ich nur geschrieben, weil ich diesen Fallback
auf libgcc für komplett unsinnig halte.  Wenn's keine libstdc++
gibt, dann kann man sie an dieser Stelle halt nicht linken, warum
dann irgendwelche Verrenkungen, stattdessen was anderes zu nehmen?

> Wie sieht's mit fixed-point aus, sind die in 854?

Nö, IEEE-854 ist floating-point.  Ah, ich konnte die beiden nie
auseinanderhalten, IEEE-754 ist wohl eher, worüber wir hier reden:

"IEEE Standard for Binary Floating-Point Arithmetic for microprocessor 
systems (ANSI/IEEE Std 754-1985)"

> Würde eigentlich ein in-tree-build der avr-libc in gcc funktionieren?

Habe ich nie probiert, könnte aber durchaus klappen.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Johann L. schrieb:
>
> (libstdc++ vs. libgcc)
>
>> hmmm. ist das gcc-Automatismus oder hilft ein eigenes specfile, also
>> -dumpspecs und das verändert wieder reinfüttern. specs sind echt der
>> Horror...
>
> Meiner Erinnerung nach (ist schon paar Jahre her) ist das ein
> GCC-Automatismus.  Sie wollen offenbar an dieser Stelle einen
> Aufruf einer Bibliothek einbauen beim Linken eines C++-Jobs, und
> wenn die Konfiguration keine libstdc++ hat (so heißt sie wohl,
> habe ich mich jetzt erinnert), dann fallen sie zurück auf eine
> libgcc.

"Sie" ist in dem Falle avr.h:
#define LIBSTDCXX "-lgcc"
/* No libstdc++ for now.  Empty string doesn't work.  */

Dieses Makro wird sehr früh von g++ ausgewertet (cp/g++spec.c), noch 
bevor die specs gelesen werden oder man sich über ne spec-Funktion 
reinhängen könnte (reinhängen ginge, aber was soll man 
zurückliefern???).
Da es keine spec ist, kann es durch eine solche später auch nicht mehr 
entfernt werden. Die einzige Möglichkeit ist daß avr.h sagt
#define LIBSTDCXX "-mvoid"

und -mvoid als versteckte Option zu akzeptieren.

> Den Bugreport habe ich nur geschrieben, weil ich diesen Fallback
> auf libgcc für komplett unsinnig halte.  Wenn's keine libstdc++
> gibt, dann kann man sie an dieser Stelle halt nicht linken, warum
> dann irgendwelche Verrenkungen, stattdessen was anderes zu nehmen?

Das Problem ist, daß man an der Stelle irgendwas nehmen muß die Frage 
ist nur: was? -lm geht ja auch nicht, da eine libm nicht unbedingt 
vorhanden ist. Ironischerweise fügt der g++-Automatismus selbst ein -lm 
ein, so daß es auf der Kommandozeile nicht mehr notwendig ist

ohne -lm (dito für -lm am Anfang und am Ende der Kommandozeile):
   -lm -lgcc -lc -lgcc
und
   -lm -lm -lgcc -lc -lgcc

wenn zwei -lm da stehen, usw.

>> Wie sieht's mit fixed-point aus, sind die in 854?

Es ging eher um die "fixed-point". In gcc gibt's die ja für lau, d.h. 
native Unterstützung für FMUL* (falls mi BE unterstützt, ansonsten 
libgcc) und das V-Flag würde aus seinem Dornröschenschlaf erwachen 
(Saturierung). Das ganze Handgefrickel mit eigener C-Bitgeschubbse oder 
inline asm für Fixedpoint hätte also ein Ende.

Dito für pgm_read_*, siehe

http://www.avrfreaks.net/index.php?name=PNphpBB2&f...

Letzteres zu unterstützen wäre aber strategisch sehr ungeschickt. Bevor 
man sowas reinbringt muss erst mal die Grundlage stimmen, d.h. die Bugs 
müssen raus. Ausserdem ist sowas, im Gegensatz zur 
Fixed-Point-Unterstützung, nicht trivial (aus BE-Sicht).

>> Würde eigentlich ein in-tree-build der avr-libc in gcc funktionieren?
>
> Habe ich nie probiert, könnte aber durchaus klappen.
# Make sure that we found the right avr cross-compiler.

case "${CC}" in
   *avr-gcc*) ;;
   *) { { $as_echo "$as_me:$LINENO: error: Wrong C compiler found; check the PATH!" >&5

Möööp. avr-gcc ist zu dem Zeitpunkt noch im Inkubator. CC ist
/mnt/nfs/home/georg/gcc/build/gcc-4.5.1-avr/./gcc/xgcc -B/mnt/nfs/home/georg/gcc/build/gcc-4.5.1-avr/./gcc/ -nostdinc -B/mnt/nfs/home/georg/gcc/build/gcc-4.5.1-avr/avr/newlib/ -isystem /mnt/nfs/home/georg/gcc/build/gcc-4.5.1-avr/avr/newlib/targ-include -isystem /gnu/source/gcc.gnu.org/tags/gcc_4_5_1_release/newlib/libc/include -B/home/georg/gcc/install/gcc-4.5.1/avr/bin/ -B/home/georg/gcc/install/gcc-4.5.1/avr/lib/ -isystem /home/georg/gcc/install/gcc-4.5.1/avr/include -isystem /home/georg/gcc/install/gcc-4.5.1/avr/sys-include

Aber nicht so tragisch, avr-libc ist ja "nur" ne target-lib. Wichtiger 
ist, daß es für die host-libs geht, was canadian cross build ganz 
komfortabel macht. (ich hab einmal versucht, nen gcc unter windos zu 
generieren. nie wieder)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Die einzige Möglichkeit ist daß avr.h sagt
> #define LIBSTDCXX "-mvoid"
>
> und -mvoid als versteckte Option zu akzeptieren.

OK, wäre eine Möglichkeit.

Eigentlich wäre es mir natürlich lieber, wir könnten mal eine
libstdc++ bauen...  Ich habe aber lange nicht mehr reingeguckt,
was man dazu ggf. noch benötigen würde.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Johann L. schrieb:
>> Die einzige Möglichkeit ist daß avr.h sagt
>> #define LIBSTDCXX "-mvoid"
>>
>> und -mvoid als versteckte Option zu akzeptieren.
>
> OK, wäre eine Möglichkeit.

Vielleicht war es damals einfach ein Missverständnis und Andrew glaubte, 
es ginge darum, was im g++ zu ändern und nicht im avr backend. Ist ja 
auch schon 4 Jahre her das ganze, vielleicht sieht er es inzwischen 
anders.

Problem: auch wenn keine avr-libc vorhanden ist steht da -lm und avr-gcc 
bricht ab mit "cannot find -lm". Das würde zB stören, wenn man die 
Testsuite gegen avr-g++ laufen lässt. (mal dahingestellt, wie sinnvoll 
das wäre ohne exceptions, templates, ...)

> Eigentlich wäre es mir natürlich lieber, wir könnten mal eine
> libstdc++ bauen...  Ich habe aber lange nicht mehr reingeguckt,
> was man dazu ggf. noch benötigen würde.

Müsste man mal antesten und gucken wo's hakt. avr-gcc unterstützt ja 
keine Trampolines, das könnte ein Problem sein falls C++ solche 
Schweinereien braucht. (Ich hab immer nen Bogen um C++ gemacht, wenn 
schon objektorientiert, dann richtig ;-))

Zu den Schikanen von C++ sgehören auch die Exceptions, aber da sollte 
nix zu machen sein. Unwind muss funktionieren und setjump/longjump, das 
geht doch schon.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.