Hi, ich würd gerne besser verstehen, wie avr-gcc und avr-libc
zusammenpassen, insbesondere auch, um
http://gcc.gnu.org/PR28718http://gcc.gnu.org/PR29524
besser zu verstehen. Die englischen Erklärungen sind mir da auch nicht
immer klar.
"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.
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.
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)
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.
Johann L. schrieb:> Hier ein einfacherer Testfall ohne floats:
Der holt sich __clzhi2 aus der libgcc.a, und diese referenziert
__clz_tab:
1
_clzhi2.o: file format elf32-avr
2
3
4
Disassembly of section .text:
5
6
00000000 <__clzhi2>:
7
0: fc 01 movw r30, r24
8
2: 8f 3f cpi r24, 0xFF ; 255
9
4: 91 05 cpc r25, r1
10
6: 01 f0 breq .+0 ; 0x8 <__clzhi2+0x8>
11
6: R_AVR_7_PCREL .text+0xa
12
8: 00 f4 brcc .+0 ; 0xa <__clzhi2+0xa>
13
8: R_AVR_7_PCREL .text+0x1c
14
a: 80 31 cpi r24, 0x10 ; 16
15
c: 91 05 cpc r25, r1
16
e: 00 f0 brcs .+0 ; 0x10 <__clzhi2+0x10>
17
e: R_AVR_7_PCREL .text+0x16
18
10: 84 e0 ldi r24, 0x04 ; 4
19
12: 90 e0 ldi r25, 0x00 ; 0
20
...
21
3e: 02 f4 brpl .+0 ; 0x40 <__clzhi2+0x40>
22
3e: R_AVR_7_PCREL .text+0x38
23
40: e0 50 subi r30, 0x00 ; 0
24
40: R_AVR_LO8_LDI_NEG __clz_tab
25
42: f0 40 sbci r31, 0x00 ; 0
26
42: R_AVR_HI8_LDI_NEG __clz_tab
27
44: 80 81 ld r24, Z
28
46: 28 1b sub r18, r24
29
48: 31 09 sbc r19, r1
30
4a: c9 01 movw r24, r18
31
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.
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?
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).
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.
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.
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.
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.
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:
1
#define LIBSTDCXX "-lgcc"
2
/* 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
1
#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&file=viewtopic&p=762995#762995
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.
1
# Make sure that we found the right avr cross-compiler.
2
3
case "${CC}" in
4
*avr-gcc*) ;;
5
*) { { $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
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)
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.
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.
Thread beobachten
Seitenaufteilung abschalten