Mikrocontroller: "Compiler-Optimizer-Fehler" finden?

[Olaf Kaluza]

Matthias Weingart <mwnews@pentax.boerde.de> wrote:

?ber sowas bin ich auch schon gestolpert, das zeigt doch mal wieder das C
eigentlich ziemlicher Murks ist.

Sagen wir mal so, es ist der Menschheit in 30Jahren schon gelungen
bessere Sprachen zu entwickeln. Aber es ist doch schoen das man immer
dieselbe Sprache verwenden kann.

Raum bewegt: Broswer,Flash,Java etc. ist da jemals abzusehen, das da kein
Sicherheitsupdate mehr n?tig ist? (Ganz abgesehen davon, das st?ndig

Nein. Ueberleg dir auch mal wieviele arbeitslose Programmierer es dann
geben duerfte.

Olaf

 

[Olaf Kaluza]

Edzard Egberts <ed_09@tantec.de> wrote:

Falscher Film, mit der Übersetzung der Sourcen hat die Eclipse nicht
viel zu tun, die ruft nur die Toolchains auf, gcc -> ld usw.
Das wird auch schön in der Konsole angezeigt und man kann diese Befehle
auch von Hand aufrufen.

Da hast du natuerlich recht. Aber wenn du dich einmal durch diese
UNERTRAEGLICHE Konfiguration von Eclipse durchgewurchkelt hast und
willst dasselbe eine Woche spaeter auf einem anderen Rechner nochmal
machen so ist es sehr unwahrscheinlich das am Ende dasselbe rauskommt.

Da ist ein Makefile einfach die einfachere Loesung. Die kann man einem
Kollegen schnell per Email schicken und man weiss das es laufen wird.

Auch wenn ich es ungern so ausdrücke, ist die Eclipse eigentlich nur die
Super-Mega-Bloat-Variante eines Texteditors und kann vollständig durch
den vi ersetzt werden. ;o)

Hihi..ich hab in der Firma Eclipse mit Emacs-compatiblen Editor
laufen. Das sorgt dafuer das die Kollegen wenn sie bei mir mal eben
was machen wollen schnell boese kucken. :-D

Aber wenn man Source hat an dem ein Dutzend Programmierer arbeiten,
Multitasking Betriebsystem, verschiedene Funktionalitaet jetzt nach
verwendeter Zielhardware dann ist der Luxus der Grafikoberflaeche
manchmal schon ganz hilfreich. Muss man auch mal zugeben, egal wie
schlimm der Rotz sonst so ist.

Olaf

 

[Johannes Bauer]

On 20.02.2015 17:17, Olaf Kaluza wrote:

Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:

Der GCC ist nämlich nicht so wirklich drauf ausgelegt, unterschiedliche
M-Architekturen alle übersetzen zu können. Einige Toolchains machen da
üble Verrenkungen, um das trotzdem hin zu kriegen. Sauber ist das nicht
und kostet -- wenn es denn schief geht -- echt Nerven.

Das wusste ich noch garnicht und es macht mir Angst. Und es fuehrt das
ganze "Hach, aber die ARMs sind ja SOOOO kompatible!" noch besonders
ins absurde, das man immer erzaehlt bekommt.

Naja, ne, das ist wirklich eine Spezialität des gcc, der in der Hinsicht
extrem doof programmiert ist. Ich hoffe ja immernoch dass der
langfristig von llvm abgelöst wird. Der ist nämlich wirklich ein Traum.

Und eignetlich "sollte" das ja mit dem gcc auch gehen. Also multilib.
Und geht wohl möglicherweise auch, wenn man bestimmte Sachen rumpatched.
Mit Vanilla hat man aber keine Chance, zumindest dann nicht, wenn man
Hardfloat mit Softfloat mischt. Da gibts dann Linkerfehler, weil die
libgcc mit dem falschen Floatset kompiliert wurde und die Selektion
funktioniert nicht richtig.

Hat mich aber auch einige Stunden im Bugtracker wühlen gekostet.
Vielleicht finde ich meine Posts von damals noch, dann verlinke ich sie
hier.

Ich glaube langsam das einzige besondere an ARM ist die
Marketingabteilung.

Also ich muss sagen ich finde Thumb2 ist ein extrem guter Wurf. Das ist
ein genial einfaches, aber trotzdem sehr mächtiges Instruction Set. Und
die Standardisierung des NVIC ist auch ziemlich cool.

Ich hab hier eigene gcc-Versionen für M0, M3 und M4 rumliegen.

Kannst du mal ein gcc -v fuer die einzelnen Versionen posten?

Klar, ist aber alles ziemlich straightforward:

joequad joe [~/bin/gcc]: arm-cm0/bin/arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-cm0/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/home/joe/bin/gcc/arm-cm0/libexec/gcc/arm-none-eabi/4.9.2/lto-wrapper
Target: arm-none-eabi
Configured with: ../configure --prefix=/home/joe/bin/gcc/arm-cm0/
--without-headers --with-gnu-ld --with-gnu-as --with-dwarf2
--disable-werror --disable-threads --disable-nls --disable-shared
--disable-libssp --disable-libmudflap --disable-libgomp
--target=arm-none-eabi --with-newlib --with-cpu=cortex-m0
--with-tune=cortex-m0 --disable-interwork --disable-multilib
--with-float=soft --with-mode=thumb --enable-languages=c
--with-system-zlib --enable-target-optspace
Thread model: single
gcc version 4.9.2 (GCC)


joequad joe [~/bin/gcc]: arm-cm3/bin/arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-cm3/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/home/joe/bin/gcc/arm-cm3/libexec/gcc/arm-none-eabi/4.8.1/lto-wrapper
Target: arm-none-eabi
Configured with: ../configure --prefix=/home/joe/bin/gcc/arm-cm3/
--with-gnu-ld --with-gnu-as --with-dwarf2 --disable-werror
--disable-threads --disable-nls --disable-shared --disable-libssp
--disable-libmudflap --disable-libgomp --target=arm-none-eabi
--with-newlib --with-cpu=cortex-m3 --with-tune=cortex-m3
--disable-interwork --disable-multilib --with-float=soft
--with-mode=thumb --enable-languages=c,c++ --with-system-zlib
--enable-target-optspace
Thread model: single
gcc version 4.8.1 (GCC)


joequad joe [~/bin/gcc]: arm-cm4/bin/arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-cm4/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/home/joe/bin/gcc/arm-cm4/libexec/gcc/arm-none-eabi/4.8.1/lto-wrapper
Target: arm-none-eabi
Configured with: ../configure --prefix=/home/joe/bin/gcc/arm-cm4/
--with-gnu-ld --with-gnu-as --with-dwarf2 --disable-werror
--disable-threads --disable-nls --disable-shared --disable-libssp
--disable-libmudflap --disable-libgomp --target=arm-none-eabi
--with-newlib --with-cpu=cortex-m4 --with-tune=cortex-m4
--disable-interwork --disable-multilib --with-fpu=fpv4-sp-d16
--with-float=hard --with-mode=thumb --enable-languages=c,c++
--with-system-zlib --enable-target-optspace
Thread model: single
gcc version 4.8.1 (GCC)

Viele Grüße,
Johannes

--

Wo hattest Du das Beben nochmal GENAU vorhergesagt?
Zumindest nicht öffentlich!

Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

 

[Ewald Pfau]

Matthias Weingart <mwnews@pentax.boerde.de>:

Broswer,Flash,Java etc. ist da jemals abzusehen, das da kein
Sicherheitsupdate mehr n?tig ist?

Konsultieren wir die unschlagbare Autorität in so wichtigen Fragen,
siehe die --> markierte <-- Stelle -

-------------------
<http://huffman.sourceforge.net/tao/tao-of-programming.html>

Book 5 - Maintenance
Thus spake the master programmer:
“Though a program be but three lines long, someday it will have to be
maintained.”

5.1
A well-used door needs no oil on its hinges.
A swift-flowing stream does not grow stagnant.
Neither sound nor thoughts can travel through a vacuum.
--> Software rots if not used. <---

These are great mysteries.
----------------------

 

[Michael Schwingen]

On 2015-02-20, Olaf Kaluza <olaf@criseis.ruhr.de> wrote:

Michael Schwingen <news-1326478115@discworld.dascon.de> wrote:


Sagen wir so: der Einstieg ist mit avrgcc und avr-libc einfacher - es gibt
nur diese eine (verbreitete) Toolchain, und jeder benutzt die.

Jeder?

[olaf] ~/sources: cross-avr-gcc -v
Using built-in specs.
COLLECT_GCC=cross-avr-gcc
COLLECT_LTO_WRAPPER=/usr/local/cross/libexec/gcc/avr/4.7.0/lto-wrapper
Target: avr
Configured with: ../gcc-4.7.0/configure --target=avr --prefix=/usr/local/cross --program-prefix=cross-avr- --enable-languages=c,c++ --disable-nls --disable-libssp --with-gnu-as --with-gnu-ld --with-newlib --with-checking=release
Thread model: single
gcc version 4.7.0 (GCC)

Ich uebersetze mir meine privaten Compiler lieber selber. Da weiss man
was man hat und vor allem ich habe denselben Versionsstand fuer alle
meine Controller.

OK - mache ich teilweise auch. Trotzdem ist das effektiv der gleiche
Compiler, mit den gleichen specs, Linkerscripten, dem gleichen Startupcode
und der gleichen libc wie der, der bei Atmel oder bei arduino verwendet
wird.

Die Unterschiede, die da auftreten, sind geringer als zwischen den
verschiedenen Kombinationen von IDE/Startupcode/Herstellerlibraries im
ARM-Umfeld.

Bis man mit einem beliebigen Cortex-M produktiv ist, ist die Schwelle höher:
irgendwie zurechtgedengelte IDEs, deren interne Projektverwaltung die
interessanten Details versteckt

Ach? Was hat denn die IDE mit dem Controller zutun? Ich benutze hier
je nach Tageslaune Emacs/Make oder Eclipse. Egal fuer welchen
Controller.

Du klickst in der IDE auf "neues Cortex-M0 Projekt mit STM32F030" und
versuchst dann, das zu übersetzen. Anstatt eines Makefiles übernimmt die
IDE die Kontrolle welcher Startupcode, welches Linkerscript etc. verwendet
wird - das kann aus dem Lieferumfang von IDE (bzw. Prozessor-Plugin) sein,
oder aus dem Portfolio des crossgcc. Teilweise werden partielle Makefiles
gebaut, wo wieder nicht klar ist, woher die restlichen Definitionen kommen.

Wenn es nicht funktioniert (oder Du nur nachsehen willst, *was* da
eigentlich passiert), ist das übel.

Ich bin auch eigentlich eher ein Freund von emacs+make, aber da ich wissen
wollte, wie das notfalls auch mal unter WIndows geht, habe ich mir die
diversen angebotenen IDEs halt mal angesehen. Als einzige brauchbare Lösung
ist dann vanilla eclipse mit OpenOCD-Debugger-Plugin übriggeblieben - und
make. Wenn es funktioniert, ist die Debugunterstützung schon sehr nett.

und die Fehlersuche extrem erschweren,

Hat den AVR mittlerweile einen brauchbaren Debugger? Als ich vor
Jahren auf die R8C mit ihrem Debugger gestossen bin habe ich nur noch
ueber AVR gelacht und alle neuen Projekte auf Renesas umgestellt.

Ich habe das auf AVR nie benutzt, die Tools und Protokolle sind IIRC nicht
wirklich offen. Auf ARM sieht es da deutlich besser aus.

Ich bin inzwischen zum Ergebnis gekommen, die ganzen
rundum-sorglos-Hersteller-IDEs liegenzulassen und nackt mit gcc-arm-embedded
plus Makefile zu übersetzen.

Das ist ja auch die uebliche vorgehensweise bei Profis. Wie willst du bei
so einem Eclipse-Monster sonst bei der Zertifizierung auch nachweisen
wie genau den Source uebersetzt wurde oder es gar spaeter reproduzieren.
Man kann allerdings trotzdem Eclipse benutzen wenn man will.

Ja - damit sind aber die ganzen von den Herstellern gepimpten
Eclipse-Versionen (Code Red, Coocox, ...) Unsinn - deren Mehrwert liegt ja
größtenteils in den Teilen, die ich mit make eh nicht benutze.

Ich wollte einfach nicht glauben, daß das wirklich so schlimm ist - das war
aber mein erster Kontakt mit Eclipse.

Andererseits: wenn man die Einstiegshürde mal überwunden hat, sind die Teile
nett. Sobald man bei einem Atmel 64k Flash braucht, ist man mit einem
passenden Cortex-M in der Regel besser bedient - und teurer sind die dann
auch nicht wirklich.

Hehe. Der Grund warum der ARM-Kram derzeit den Markt aufrollt ist das
er schlicht billiger ist.

Was ja nicht schlecht ist - wenn ich für weniger Geld eine CPU bekomme, wo
ich mich nicht mit den Einschränkungen des AVR 'rumschlagen muß, ist das OK.

der Unterschied ist dann
nur in der Peripherie um den CPU-Kern herum.

Nur ist gut! Das ist bei einem Controller der MEGAENTSCHEIDENDE
Unterschied. Da die Programmierung in C erfolgt ist der Core
nebensaechlich. Es erstaunt mich immer wieder wie sich da Leute die
es selber besser wissen muessten selber einen in die Tasche luegen.

Schon klar. Und auch da ist das Feld weit - ARM hat derzeit den Vorteil, daß
die Tool-Unterstützung gut ist, und die Unterschiede, die es zwischen den
herstellern gibt, liegen eher an der Peripherie oder der Prozeßtechnologie.
Wenn die Meldungen zum neuen STM32L4 stimmen (sprich: braucht wirklich
weniger Strom als ein MSP430), ist das ein gutes Beispiel dafür.

Wobei: im Batteriebetrieb sind die ganzen Herstellerangaben ja sowieso mit
extremer Vorsicht zu genießen. Interessanter Artikel, der die
Marketing-Angaben von "10 Jahre mit einer Batterie" ins rechte Licht rückt:

http://www.ganssle.com/reports/ultra-low-power-design.html

ST hat günstige Evalboards incl. Debugger, die gescheit mit
Open-Source-Tools funktionieren - NXP eher nicht, für den LPC1768 habe ich
einen ST-Link zum Debuggen genommen.

Das geht? Haette ich jetzt nicht gedacht. Allerdings finde ich die
paar Kroeten fuer einen JLink-Edu auch okay. Schon erstaunlich was
moeglich ist wenn in China die Nachbauten vom Fliessband hopsen.

Ja, tut bestens - der ST-Link war halt als einer der ersten mit
SWD-Unterstützung im OpenOCD dabei. Was mir an den ARMs gefällt, ist die
Offenheit - die Kerne sind incl. Debug-Schnittstelle gescheit dokumentiert,
so daß es brauchbare freie Tools dafür gibt.

Beruflich nutze ich derzeit Silabs/Gecko. Die sind technisch in
Ordnung. (vielleicht von ihrem beknackten Gehauese mit dem fetten
Massepad mal abgesehen)

Die LPC812 sind süß ...

Bloss die Datenblaetter...manoman. Die wurden wohl von einem
Marketinghengst mit Powerpoint (ausspuck) geschrieben.

Die ST-Datenblätter sind OK, aber teilweise etwas unübersichtlich verteilt -
subjektiv aber grob in der Klasse wie die Freescale-PowerPC-CPUs, die wir in
der Firma einsetzen und damit durchaus benutzbar.

cu
Michael

 

[Michael Schwingen]

On 2015-02-20, Edzard Egberts <ed_09@tantec.de> wrote:

Das ist ja auch die uebliche vorgehensweise bei Profis. Wie willst du bei
so einem Eclipse-Monster sonst bei der Zertifizierung auch nachweisen
wie genau den Source uebersetzt wurde oder es gar spaeter reproduzieren.

Falscher Film, mit der Übersetzung der Sourcen hat die Eclipse nicht
viel zu tun, die ruft nur die Toolchains auf, gcc -> ld usw.
Das wird auch schön in der Konsole angezeigt und man kann diese Befehle
auch von Hand aufrufen.

Ja. Aber wie sage ich z.B. einem Coocox-Eclipse, daß ich jetzt einen anderen
Startupcode haben will, und nicht den, den er nimmt? das ist IMHO tief in
irgendwelchen Plugins versteckt und nicht wirklich im Projekt
konfigurierbar. Wenn man das Projekt nicht explizit auf "ich habe eigene
Makefiles" einstellt, übernimmt Eclipse selber die Kontrolle, was wie mit
welchen Optionen gebaut wird.

Auch wenn ich es ungern so ausdrücke, ist die Eclipse eigentlich nur die
Super-Mega-Bloat-Variante eines Texteditors und kann vollständig durch
den vi ersetzt werden. ;o)

Wenn Du keinen Sourcelevel-Debugger benutzt: korrekt.

Eclipse übernimmt halt nicht nur die Aufgaben des Editors, sondern auch von
make, makefile, gdb + gdb-Frontend.

cu
Michael

 

[Marc Santhoff]

Michael Schwingen <news-1326478115@discworld.dascon.de> schrieb:

On 2015-02-20, Olaf Kaluza <olaf@criseis.ruhr.de> wrote:
Michael Schwingen <news-1326478115@discworld.dascon.de> wrote:

Bis man mit einem beliebigen Cortex-M produktiv ist, ist die
Schwelle höher: irgendwie zurechtgedengelte IDEs, deren interne
Projektverwaltung die interessanten Details versteckt

Ach? Was hat denn die IDE mit dem Controller zutun? Ich benutze hier
je nach Tageslaune Emacs/Make oder Eclipse. Egal fuer welchen
Controller.

Du klickst in der IDE auf "neues Cortex-M0 Projekt mit STM32F030" und
versuchst dann, das zu übersetzen. Anstatt eines Makefiles übernimmt
die IDE die Kontrolle welcher Startupcode, welches Linkerscript etc.
verwendet wird - das kann aus dem Lieferumfang von IDE (bzw.
Prozessor-Plugin) sein, oder aus dem Portfolio des crossgcc.
Teilweise werden partielle Makefiles gebaut, wo wieder nicht klar
ist, woher die restlichen Definitionen kommen.

Wenn es nicht funktioniert (oder Du nur nachsehen willst, *was* da
eigentlich passiert), ist das übel.

Ich bin auch eigentlich eher ein Freund von emacs+make, aber da ich
wissen wollte, wie das notfalls auch mal unter WIndows geht, habe ich
mir die diversen angebotenen IDEs halt mal angesehen. Als einzige
brauchbare Lösung ist dann vanilla eclipse mit
OpenOCD-Debugger-Plugin übriggeblieben - und make. Wenn es
funktioniert, ist die Debugunterstützung schon sehr nett.

Oder man geht anders vor, das meint Olaf wohl:

Neues Projekt erzeugen, aber nicht mit der Standardeinstellung für
"project root" und dann den Ort angeben, wo die Quellen und das
Makefile liegen. Da packt Ecslipse dann nur ein paar Verzeichnisse dazu
(.project und ein oder zwei andere).

Dann noch das Standard Build Kommando auf make -f ... setzen, und man
kann auch aus Eclipse make benutzen wie bisher und trotzdem per vi
oder auch edlin von der Konsole arbeiten.

Ich bin inzwischen zum Ergebnis gekommen, die ganzen
rundum-sorglos-Hersteller-IDEs liegenzulassen und nackt mit
gcc-arm-embedded plus Makefile zu übersetzen.

Das ist ja auch die uebliche vorgehensweise bei Profis. Wie willst
du bei so einem Eclipse-Monster sonst bei der Zertifizierung auch
nachweisen wie genau den Source uebersetzt wurde oder es gar
spaeter reproduzieren. Man kann allerdings trotzdem Eclipse
benutzen wenn man will.

Ja - damit sind aber die ganzen von den Herstellern gepimpten
Eclipse-Versionen (Code Red, Coocox, ...) Unsinn - deren Mehrwert
liegt ja größtenteils in den Teilen, die ich mit make eh nicht
benutze.

Ich wollte einfach nicht glauben, daß das wirklich so schlimm ist -
das war aber mein erster Kontakt mit Eclipse.

Man muß sich schon Zeit nehmen zu lernen, die Doku ist jedenfalls
umfangreich und detailliert.

Klar, Konfiguration ist ggf. eklig oder frickelig, aber nur eimalig zu
erledigen, unterstützt durch x-fach vorhandene Tutorien. Und im
professionellen Umfeld sollte die dann auch sorgfältig dokumentiert und
akribisch mit den benutzten Software-Versionen archiviert sein.

Das sind die Kosten, gewinnen tut man grafischen Schnickschnack:

- Code Folding
- Syntax Highlighting
- Quelltextnavigation
- Debugger eingebunden
- Unit Test übersichtlich
- Versionsverwaltung ebenfalls,
usw., usw.

Ich finde es jedenfalls ab einer kritischen Masse gerechtfertigt und
deutlich produktiver, leistungsfähige IDEs zu benutzen. Bei
Trivialprogrammen, LED am Mega8 blinken lassen, lohnt es aber kaum.

Marc

 

[Michael Schwingen]

On 2015-02-22, Marc Santhoff <m.santhoff@t-online.de> wrote:

Michael Schwingen <news-1326478115@discworld.dascon.de> schrieb:

On 2015-02-20, Olaf Kaluza <olaf@criseis.ruhr.de> wrote:
Michael Schwingen <news-1326478115@discworld.dascon.de> wrote:


Bis man mit einem beliebigen Cortex-M produktiv ist, ist die
Schwelle höher: irgendwie zurechtgedengelte IDEs, deren interne
Projektverwaltung die interessanten Details versteckt

Ach? Was hat denn die IDE mit dem Controller zutun? Ich benutze hier
je nach Tageslaune Emacs/Make oder Eclipse. Egal fuer welchen
Controller.

Du klickst in der IDE auf "neues Cortex-M0 Projekt mit STM32F030" und
versuchst dann, das zu übersetzen. Anstatt eines Makefiles übernimmt
die IDE die Kontrolle welcher Startupcode, welches Linkerscript etc.
verwendet wird - das kann aus dem Lieferumfang von IDE (bzw.
Prozessor-Plugin) sein, oder aus dem Portfolio des crossgcc.
Teilweise werden partielle Makefiles gebaut, wo wieder nicht klar
ist, woher die restlichen Definitionen kommen.

Wenn es nicht funktioniert (oder Du nur nachsehen willst, *was* da
eigentlich passiert), ist das übel.

Ich bin auch eigentlich eher ein Freund von emacs+make, aber da ich
wissen wollte, wie das notfalls auch mal unter WIndows geht, habe ich
mir die diversen angebotenen IDEs halt mal angesehen. Als einzige
brauchbare Lösung ist dann vanilla eclipse mit
OpenOCD-Debugger-Plugin übriggeblieben - und make. Wenn es
funktioniert, ist die Debugunterstützung schon sehr nett.

Oder man geht anders vor, das meint Olaf wohl:

Neues Projekt erzeugen, aber nicht mit der Standardeinstellung für
"project root" und dann den Ort angeben, wo die Quellen und das
Makefile liegen. Da packt Ecslipse dann nur ein paar Verzeichnisse dazu
(.project und ein oder zwei andere).

Dann noch das Standard Build Kommando auf make -f ... setzen, und man
kann auch aus Eclipse make benutzen wie bisher und trotzdem per vi
oder auch edlin von der Konsole arbeiten.

Äh - liest Du eigentlich, was ich hier schreibe?

Das ist doch genau das, was ich nach Ausprobieren dieser IDE-Sackgasse
gemacht (und weiter oben im Thread beschrieben) habe.

Das ist nur die Methode, die von den Chipherstellern nicht unterstützt wird
(gerade nochmal nachgesehen: ST liefert zwar eigenen Startupcode mit ihrem
HAL-Framework, aber kein dazu passendes Linkerscript - und das von
gcc-arm-embedded passt nicht zu den ST-Sourcen). Wenn man sich das selber
passend macht, klappt es - aber dann brauche ich kein STM32-Plugin für
Eclipse mehr.

Wobei: bei TI gibt es im Quickstart Guide zum CC3200 tatsächlich ein Kapitel
"wie mache ich das mit einem nackten gcc + make" - es besteht also noch
Hoffnung!

Ich wollte einfach nicht glauben, daß das wirklich so schlimm ist -
das war aber mein erster Kontakt mit Eclipse.

Man muß sich schon Zeit nehmen zu lernen, die Doku ist jedenfalls
umfangreich und detailliert.

Dann gib' mir bitte mal Starthilfe und erklär' mir, wie ich mit dem in
Eclipse eingebauten Buildsystem konfiguriere, welches Linkerscript und
welchen Startupcode er nimmt (Makefile gilt nicht - *das* funktioniert, aber
dann sind halt die ganzen Konfigurationsdialoge in eclipse für die Katz').
Mein Kollege mit längerer embedded-Eclipse-Erfahrung konnte mir da nicht
helfen (dafür an anderer Stelle - der Indexer findet jetzt tatsächlich nur
die Sourcen, die auch zum Projekt gehören).

Klar, Konfiguration ist ggf. eklig oder frickelig, aber nur eimalig zu
erledigen, unterstützt durch x-fach vorhandene Tutorien. Und im
professionellen Umfeld sollte die dann auch sorgfältig dokumentiert und
akribisch mit den benutzten Software-Versionen archiviert sein.

Ich bin nicht wirklich überzeugt, daß Dokumentation der Art "klicken Sie
hier auf Option X" wirklich zu reproduzierbaren Builds führt, wenn man das
mal auf einem Ersatzrechner hochziehen muß. Wenn dann Teile der Sourcen (der
Startupcode gehört für mich dazu) von Eclipse (incl. Plugin) geliefert wird
und nicht aus meinen Sourcen und auch nicht vom Compiler/libc-Paket, dann
ist es mit der Reproduzierbarkeit völlig vorbei - solche Abhängigkeiten kann
ich nicht ins Versionskontrollsystem einchecken.

Das sind die Kosten, gewinnen tut man grafischen Schnickschnack:

- Code Folding
- Syntax Highlighting
- Quelltextnavigation
- Debugger eingebunden
- Unit Test übersichtlich
- Versionsverwaltung ebenfalls,
usw., usw.

Ich finde es jedenfalls ab einer kritischen Masse gerechtfertigt und
deutlich produktiver, leistungsfähige IDEs zu benutzen. Bei
Trivialprogrammen, LED am Mega8 blinken lassen, lohnt es aber kaum.

Ich sehe einen Teil der Vorteile, aber wirklich spürbar besser als bei
emacs+Terminal ist nur die Debugger-Integration. Dafür ist es dann zäher zu
bedienen, weil ich öfter zur Maus greifen muß.

cu
Michael

 

[Marc Santhoff]

Michael Schwingen <news-1326478115@discworld.dascon.de> schrieb:

On 2015-02-22, Marc Santhoff <m.santhoff@t-online.de> wrote:
Michael Schwingen <news-1326478115@discworld.dascon.de> schrieb:

On 2015-02-20, Olaf Kaluza <olaf@criseis.ruhr.de> wrote:
Michael Schwingen <news-1326478115@discworld.dascon.de> wrote:


Bis man mit einem beliebigen Cortex-M produktiv ist, ist die
Schwelle höher: irgendwie zurechtgedengelte IDEs, deren interne
Projektverwaltung die interessanten Details versteckt

Ach? Was hat denn die IDE mit dem Controller zutun? Ich benutze
hier je nach Tageslaune Emacs/Make oder Eclipse. Egal fuer
welchen Controller.

Du klickst in der IDE auf "neues Cortex-M0 Projekt mit STM32F030"
und versuchst dann, das zu übersetzen. Anstatt eines Makefiles
übernimmt die IDE die Kontrolle welcher Startupcode, welches
Linkerscript etc. verwendet wird - das kann aus dem Lieferumfang
von IDE (bzw. Prozessor-Plugin) sein, oder aus dem Portfolio des
crossgcc. Teilweise werden partielle Makefiles gebaut, wo wieder
nicht klar ist, woher die restlichen Definitionen kommen.

Wenn es nicht funktioniert (oder Du nur nachsehen willst, *was* da
eigentlich passiert), ist das übel.

Ich bin auch eigentlich eher ein Freund von emacs+make, aber da ich
wissen wollte, wie das notfalls auch mal unter WIndows geht, habe
ich mir die diversen angebotenen IDEs halt mal angesehen. Als
einzige brauchbare Lösung ist dann vanilla eclipse mit
OpenOCD-Debugger-Plugin übriggeblieben - und make. Wenn es
funktioniert, ist die Debugunterstützung schon sehr nett.

Oder man geht anders vor, das meint Olaf wohl:

Neues Projekt erzeugen, aber nicht mit der Standardeinstellung für
"project root" und dann den Ort angeben, wo die Quellen und das
Makefile liegen. Da packt Ecslipse dann nur ein paar Verzeichnisse
dazu (.project und ein oder zwei andere).

Dann noch das Standard Build Kommando auf make -f ... setzen, und
man kann auch aus Eclipse make benutzen wie bisher und trotzdem per
vi oder auch edlin von der Konsole arbeiten.

Äh - liest Du eigentlich, was ich hier schreibe?

Schon, aber scheinbar zu flüchtig bzw. fehlte mir ein wenig Redundanz
in deinem Vortrag.

Das ist doch genau das, was ich nach Ausprobieren dieser IDE-Sackgasse
gemacht (und weiter oben im Thread beschrieben) habe.

Das ist nur die Methode, die von den Chipherstellern nicht
unterstützt wird (gerade nochmal nachgesehen: ST liefert zwar eigenen
Startupcode mit ihrem HAL-Framework, aber kein dazu passendes
Linkerscript - und das von gcc-arm-embedded passt nicht zu den
ST-Sourcen). Wenn man sich das selber passend macht, klappt es - aber
dann brauche ich kein STM32-Plugin für Eclipse mehr.

Die gehen einen anderen Weg. Da gibt es doch dieses .... ach da,
STM32CubeMX. Entweder standalone oder auch als Eclipse-Plugin. DAmit
wird ein passendes Project Template erstellt.

Wobei: bei TI gibt es im Quickstart Guide zum CC3200 tatsächlich ein
Kapitel "wie mache ich das mit einem nackten gcc + make" - es besteht
also noch Hoffnung!

Ich wollte einfach nicht glauben, daß das wirklich so schlimm ist -
das war aber mein erster Kontakt mit Eclipse.

Man muß sich schon Zeit nehmen zu lernen, die Doku ist jedenfalls
umfangreich und detailliert.

Dann gib' mir bitte mal Starthilfe und erklär' mir, wie ich mit dem in
Eclipse eingebauten Buildsystem konfiguriere, welches Linkerscript und
welchen Startupcode er nimmt (Makefile gilt nicht - *das*
funktioniert, aber dann sind halt die ganzen Konfigurationsdialoge in
eclipse für die Katz').

Kann ich aus dem Ärmel auch nicht sagen, eben weil ich Makefiles
benutze. <g>

Ich würde erstmal die "Build Configurations" anpassen wollen, da sollte
sich sowas lösen lassen. Damit wird doch die Abstraktion zum konkreten
Build-Werkzeug hergestellt.

Mein Kollege mit längerer
embedded-Eclipse-Erfahrung konnte mir da nicht helfen (dafür an
anderer Stelle - der Indexer findet jetzt tatsächlich nur die
Sourcen, die auch zum Projekt gehören).

Dürfte per "C/C++ General - Path and Symbols - Includes" in
den Projektoptionen einzustellen sein, Pfadliste passend
zurechtdengeln. Oder für den Indexer nochmal separat?

Klar, Konfiguration ist ggf. eklig oder frickelig, aber nur eimalig
zu erledigen, unterstützt durch x-fach vorhandene Tutorien. Und im
professionellen Umfeld sollte die dann auch sorgfältig dokumentiert
und akribisch mit den benutzten Software-Versionen archiviert sein.

Ich bin nicht wirklich überzeugt, daß Dokumentation der Art "klicken
Sie hier auf Option X" wirklich zu reproduzierbaren Builds führt,
wenn man das mal auf einem Ersatzrechner hochziehen muß. Wenn dann
Teile der Sourcen (der Startupcode gehört für mich dazu) von Eclipse
(incl. Plugin) geliefert wird und nicht aus meinen Sourcen und auch
nicht vom Compiler/libc-Paket, dann ist es mit der Reproduzierbarkeit
völlig vorbei - solche Abhängigkeiten kann ich nicht ins
Versionskontrollsystem einchecken.

So will ich das auch nicht haben. Allerdings sollten all diese
Einstellungen eben in den Projektspezifischen Konfigurationsdateien von
Eclipse zu finden sein, die gehören ins Repository.

Das sind die Kosten, gewinnen tut man grafischen Schnickschnack:

- Code Folding
- Syntax Highlighting
- Quelltextnavigation
- Debugger eingebunden
- Unit Test übersichtlich
- Versionsverwaltung ebenfalls,
usw., usw.

Ich finde es jedenfalls ab einer kritischen Masse gerechtfertigt und
deutlich produktiver, leistungsfähige IDEs zu benutzen. Bei
Trivialprogrammen, LED am Mega8 blinken lassen, lohnt es aber kaum.

Ich sehe einen Teil der Vorteile, aber wirklich spürbar besser als bei
emacs+Terminal ist nur die Debugger-Integration. Dafür ist es dann
zäher zu bedienen, weil ich öfter zur Maus greifen muß.

Tastenkürzel sind konfigurierbar.

Wie benutzt Du dann Debugger und andere externe Tools, in Emacs im
Subfenster oder in parallelen Terminals? Bei Emacs hast Du ebenso das
Einbindungsproblem (+Lisp), bei Terminals hampelt man wie doof mit
Alt-Tab rum - nicht viel schneller IMHO, aber jeder hat so seine
Arbeitsweise.

Marc

 

[Marc Santhoff]

Marc Santhoff <m.santhoff@t-online.de> schrieb:

Dann gib' mir bitte mal Starthilfe und erklär' mir, wie ich mit dem
in Eclipse eingebauten Buildsystem konfiguriere, welches
Linkerscript und welchen Startupcode er nimmt (Makefile gilt nicht
- *das* funktioniert, aber dann sind halt die ganzen
Konfigurationsdialoge in eclipse für die Katz').

Kann ich aus dem Ärmel auch nicht sagen, eben weil ich Makefiles
benutze. <g

Ich würde erstmal die "Build Configurations" anpassen wollen, da
sollte sich sowas lösen lassen. Damit wird doch die Abstraktion zum
konkreten Build-Werkzeug hergestellt.

Ist auch so, vorausgesetzt das C-Projekt ist auf "managed make"
eingestellt.

In den Projektattributen eine neue Build Configuration erstellen, dabei
die bestehende Kopieren. Dann in den Einstellungen für den Linker
einfach nur bei den Optionen ein fröhliches "-Tram.ld" eintragen -
oder was Du so machen möchtest.

Dann kann man im Menü Project - Build die aktive Konfigruation
setzen, ausführen dann mit STRG-b wie immer.

Die grundsätzliche Projekterstellung mit den Einstellungen aus dem
Makefile kann man lösen, indem man ein vorhndenes Projekt in eine
neues, erstmal leeres C-Projekt importiert und sich daraus eine
Schablone bastelt.

Die Einstellung landen nicht wie ich vermutete in Verzeichnissen sondern
i.d.F. in der Datei ".cproject" im Quellverzeichnis bzw. beim
Projekt-Hauptknoten.

Marc

 

[Michael Schwingen]

On 2015-02-22, Marc Santhoff <m.santhoff@t-online.de> wrote:

Das ist nur die Methode, die von den Chipherstellern nicht
unterstützt wird (gerade nochmal nachgesehen: ST liefert zwar eigenen
Startupcode mit ihrem HAL-Framework, aber kein dazu passendes
Linkerscript - und das von gcc-arm-embedded passt nicht zu den
ST-Sourcen). Wenn man sich das selber passend macht, klappt es - aber
dann brauche ich kein STM32-Plugin für Eclipse mehr.

Die gehen einen anderen Weg. Da gibt es doch dieses .... ach da,
STM32CubeMX. Entweder standalone oder auch als Eclipse-Plugin. DAmit
wird ein passendes Project Template erstellt.

Ja. Nette Idee, funktioniert auch grundlegend und ist als Starthilfe sehr
nett. Der code des HAL scheint mir etwas dick zu sein - zusammen mit der
nicht superkompakten newlibc-nano kommt ein LED-Blinken-HelloWorld auf 5k
Code (knapp 4k mit -flto), aber optimieren kann man später, wenn es
funktioniert, und nur da, wo es drückt.

Dummerweise erzeugt STM32CubeMX ein Projekttemplate mit Code, wo
Linkerscript und Makefile fehlen - und die vom gcc nicht passen.

Mein Kollege mit längerer
embedded-Eclipse-Erfahrung konnte mir da nicht helfen (dafür an
anderer Stelle - der Indexer findet jetzt tatsächlich nur die
Sourcen, die auch zum Projekt gehören).

Dürfte per "C/C++ General - Path and Symbols - Includes" in
den Projektoptionen einzustellen sein, Pfadliste passend
zurechtdengeln. Oder für den Indexer nochmal separat?

Nein. Mein Makefile setzt abhängig vom target unterschiedliche Includepfade,
z.B. für den HAL für 32F0xx vs. 32F1xx, und teilweise noch je nach C-File
unterschiedlich - das läßt sich in den Projektsettings nur schlecht statisch
abbilden. Aber: der build parser kann sich das prinzipiell aus den
Compilerausgaben beim make zusammenpuzzeln, wenn man ihm sagt, daß der
Compiler nicht "gcc", sondern ".*gcc" heißen darf. Wenn es funktioniert
(aktuell hakt es teilweise unter Windows wieder), ist das definitiv sehr
nett, auf Knopfdruck an die *richtige* Stelle zu springen, wo ein Symbol
definiert ist.

Ich bin nicht wirklich überzeugt, daß Dokumentation der Art "klicken
Sie hier auf Option X" wirklich zu reproduzierbaren Builds führt,
wenn man das mal auf einem Ersatzrechner hochziehen muß. Wenn dann
Teile der Sourcen (der Startupcode gehört für mich dazu) von Eclipse
(incl. Plugin) geliefert wird und nicht aus meinen Sourcen und auch
nicht vom Compiler/libc-Paket, dann ist es mit der Reproduzierbarkeit
völlig vorbei - solche Abhängigkeiten kann ich nicht ins
Versionskontrollsystem einchecken.

So will ich das auch nicht haben. Allerdings sollten all diese
Einstellungen eben in den Projektspezifischen Konfigurationsdateien von
Eclipse zu finden sein, die gehören ins Repository.

Gut, damit ist man dann auf exakt diese Eclipse-Version und -Umgebung
festgenagelt. Ein Projekt aus Coocox (das ja auch eigentlich nur eine
eclipse-Variante zu sein scheint) läßt sich in einer nackten eclipse
jedenfalls nicht übernehmen. Ich denke, das spricht wieder sehr für
Makefiles

Ich sehe einen Teil der Vorteile, aber wirklich spürbar besser als bei
emacs+Terminal ist nur die Debugger-Integration. Dafür ist es dann
zäher zu bedienen, weil ich öfter zur Maus greifen muß.

Tastenkürzel sind konfigurierbar.

Ja, aber gefühlt brauche ich mehr Aktionen, gerade um Fenster zu wechseln.
Gut möglich, daß das besser geht, wenn mansich das alles mal passend
einstellt.

Wie benutzt Du dann Debugger und andere externe Tools, in Emacs im
Subfenster oder in parallelen Terminals? Bei Emacs hast Du ebenso das
Einbindungsproblem (+Lisp), bei Terminals hampelt man wie doof mit
Alt-Tab rum - nicht viel schneller IMHO, aber jeder hat so seine
Arbeitsweise.

Make im emacs, gdb/ddd extern per Terminal. Wenn man zwischen passenden
virtuellen screens umschaltet, geht das recht gut - das ist aber definitiv
der Punkt, der bei der Eclipse-Lösung dicke Pluspunkte sammelt.

cu
Michael

 

[Michael Schwingen]

On 2015-02-23, Marc Santhoff <m.santhoff@t-online.de> wrote:

Ich würde erstmal die "Build Configurations" anpassen wollen, da
sollte sich sowas lösen lassen. Damit wird doch die Abstraktion zum
konkreten Build-Werkzeug hergestellt.

Ist auch so, vorausgesetzt das C-Projekt ist auf "managed make"
eingestellt.

In den Projektattributen eine neue Build Configuration erstellen, dabei
die bestehende Kopieren. Dann in den Einstellungen für den Linker
einfach nur bei den Optionen ein fröhliches "-Tram.ld" eintragen -
oder was Du so machen möchtest.

Danke - gut versteckt, mal probieren. Wobei: so richtig drängt es nicht
mehr, Make ist besser verständlich.

cu
Michael

 

[Marc Santhoff]

Michael Schwingen <news-1326478115@discworld.dascon.de> schrieb:

Ich bin nicht wirklich überzeugt, daß Dokumentation der Art
"klicken Sie hier auf Option X" wirklich zu reproduzierbaren
Builds führt, wenn man das mal auf einem Ersatzrechner hochziehen
muß. Wenn dann Teile der Sourcen (der Startupcode gehört für mich
dazu) von Eclipse (incl. Plugin) geliefert wird und nicht aus
meinen Sourcen und auch nicht vom Compiler/libc-Paket, dann ist es
mit der Reproduzierbarkeit völlig vorbei - solche Abhängigkeiten
kann ich nicht ins Versionskontrollsystem einchecken.

So will ich das auch nicht haben. Allerdings sollten all diese
Einstellungen eben in den Projektspezifischen Konfigurationsdateien
von Eclipse zu finden sein, die gehören ins Repository.

Gut, damit ist man dann auf exakt diese Eclipse-Version und -Umgebung
festgenagelt. Ein Projekt aus Coocox (das ja auch eigentlich nur eine
eclipse-Variante zu sein scheint) läßt sich in einer nackten eclipse
jedenfalls nicht übernehmen. Ich denke, das spricht wieder sehr für
Makefiles

Ist da in deinem Umfeld eine ernstgemeinte Anforderung, aus beliebigen
anderen IDEen die Projekte nach Eclipse zu übernehmen? OK, wenn man vom
Hersteller oder aus dritter Quelle Zeugs geliefert bekommt, daß man
benutzen muß, da wäre vorstellbar.

Wenn man sowas tatsächlich oft oder wiederkehrend machen muß, würde man
sicher über ein Konverterprogramm nachdenken, in Konfigurationsdateien
geht es gewöhnlich streng formal zu.

Marc

 

[Marc Santhoff]

Michael Schwingen <news-1326478115@discworld.dascon.de> schrieb:

On 2015-02-23, Marc Santhoff <m.santhoff@t-online.de> wrote:
Ich würde erstmal die "Build Configurations" anpassen wollen, da
sollte sich sowas lösen lassen. Damit wird doch die Abstraktion zum
konkreten Build-Werkzeug hergestellt.

Ist auch so, vorausgesetzt das C-Projekt ist auf "managed make"
eingestellt.

In den Projektattributen eine neue Build Configuration erstellen,
dabei die bestehende Kopieren. Dann in den Einstellungen für den
Linker einfach nur bei den Optionen ein fröhliches "-Tram.ld"
eintragen - oder was Du so machen möchtest.

Danke - gut versteckt, mal probieren. Wobei: so richtig drängt es
nicht mehr, Make ist besser verständlich.

Ich hab's nur aus Neugier rausgesucht und dabei eine Menge über CDT
gelernt. Garnicht so geheimnisvoll eigentlich, und die Doku ist ganz OK.
Außerdem habe ich dabei gelernt, daß Makefiles *doch* besser sind.

Marc

 

[Michael Schwingen]

On 2015-02-25, Marc Santhoff <m.santhoff@t-online.de> wrote:

Gut, damit ist man dann auf exakt diese Eclipse-Version und -Umgebung
festgenagelt. Ein Projekt aus Coocox (das ja auch eigentlich nur eine
eclipse-Variante zu sein scheint) läßt sich in einer nackten eclipse
jedenfalls nicht übernehmen. Ich denke, das spricht wieder sehr für
Makefiles

Ist da in deinem Umfeld eine ernstgemeinte Anforderung, aus beliebigen
anderen IDEen die Projekte nach Eclipse zu übernehmen? OK, wenn man vom
Hersteller oder aus dritter Quelle Zeugs geliefert bekommt, daß man
benutzen muß, da wäre vorstellbar.

Sagen wir so: ich erwarte eigentlich, daß ich ein C-Projekt mit
verschiedenen IDEs übersetzen kann. Wenn das zwischen Eclipse-Varianten
schon nicht geht, ist das für mich nicht wirklich eine Methode, auf die ich
für die Zukunft setzen möchte - das ist so wie schematic entry für FPGAs, wo
dann beim nächsten Update der Hersteller ein neues schematic frontend
liefert - ohne Konverter, um die alten Designs importieren zu können.
Außerdem möchte man das auch in einer nicht-graphischen Umgebung
(buildserver) übersetzen können. Außerdem möchte ich nicht diverse
Eclipse-Herstellervarianten parallel auf einem Rechner installieren, um dann
je nach Projekt zwischen denen hin- und herzuwechseln.

Ich war beim Start irgendwie naiv davon ausgegangen, daß Eclipse halt ein
Makefile erstellt, welches man dann benutzen kann - das war wohl zuviel
erwartet.

Wie gesagt: nachdem ich meine Erwartungen neu justiert und auf manuell
erstellte Makefiles umgestellt habe, funktioniert alles, wie es soll.

cu
Michael

 

[Edzard Egberts]

Michael Schwingen wrote:

Sagen wir so: ich erwarte eigentlich, daß ich ein C-Projekt mit
verschiedenen IDEs übersetzen kann. Wenn das zwischen Eclipse-Varianten
schon nicht geht, ist das für mich nicht wirklich eine Methode, auf die ich
für die Zukunft setzen möchte

Na ja, man kann sich da aber schon behelfen, indem man die Eclipse für
die jeweilige Umgebung einrichtet, so ein Projekt für weitere Projekte
dann als Template kopiert und bloß die Sourcen einfügt (.h, .cpp, .c,
etc.). Meine Linux-Sourcen synce ich bloß auf die VMs und kann den Code
dann direkt in der Windows-Eclipse laufen lassen.

 

[Manuel Reimer]

Hallo,

mal ein Nachtrag zu dem Thema. Habe den Fehler gefunden:

https://github.com/M-Reimer/maple-bootloader/commit/69ed54a

Das ich nicht eingrenzen konnte hat daran gelegen, dass ich nicht
beachtet habe, dass der nicht optimierte Bootloader ja viel größer wird.
Ich musste also die Zieladresse, an die die eigentliche Firmware
geflasht wird, nach hinten verlegen.

So konnte ich dann erst schrittweise immer mehr Dateien mit "-Os"
kompilieren bis die problematische Datei gefunden war. In dieser dann
mit Attributen auf Funktionen runterbrechen und wenn die gefundene
Funktion zu groß ist diese in kleinere Funktionen runterbrechen bis man
die problematischen Zeilen gefunden hat.

Gruß

Manuel

 

[Michael Schwingen]

On 2015-03-02, Manuel Reimer <Manuel.Nulldevice@nurfuerspam.de> wrote:

Hallo,

mal ein Nachtrag zu dem Thema. Habe den Fehler gefunden:

https://github.com/M-Reimer/maple-bootloader/commit/69ed54a

Ohne Lesen der restlichen Sourcen ist mir jetzt nicht so wirklich klar, was
die Ursache war bzw. was die Änderung wirklich tut?

Zumindest das "volatile" in jumpToUser erschließt sich mir nicht - das sieht
mir mehr nach Flicken aus als nach "Ursache beheben".

cu
Michael

 

[Johannes Bauer]

On 04.03.2015 15:12, Michael Schwingen wrote:

On 2015-03-02, Manuel Reimer <Manuel.Nulldevice@nurfuerspam.de> wrote:
Hallo,

mal ein Nachtrag zu dem Thema. Habe den Fehler gefunden:

https://github.com/M-Reimer/maple-bootloader/commit/69ed54a

Ohne Lesen der restlichen Sourcen ist mir jetzt nicht so wirklich klar, was
die Ursache war bzw. was die Änderung wirklich tut?

Ja, müsste man im Assembly direkt vergleichen. Ich habe es auch
angeschaut und mir dasselbe gedacht.

Grundsätzlich ist das aber, wie ja im Thread schon angesprochen wurde,
eindeutig UB, mit einem integers Arithmetik zu machen und den dan in
einen Pointer zu casten. Und der geladene Funktionspointer wird wiederum
erst in einen Integer überführt, weiß auch nicht wieso.

Und nur am Rande verstehe ich auch nicht, warum immer jedermann seine
eigenen typedefs a la "u32" und "vu32" verwenden muss. Wahrscheinlich
auch noch irgendwo ein "#define TRUE 1", statt dass die Leute einfach
<stdint.h> und <stdbool.h> verwenden :-/

Die zweite Änderung kann ich gar nicht beurteilen.

Sieht aber beides danach aus, als ob der GCC einfach nur seine
Freiheitsgrade verwendet hat.

Viele Grüße,
Johannes

--

Wo hattest Du das Beben nochmal GENAU vorhergesagt?
Zumindest nicht öffentlich!

Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

 

[Michael Schwingen]

On 2015-03-04, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:

Grundsätzlich ist das aber, wie ja im Thread schon angesprochen wurde,
eindeutig UB, mit einem integers Arithmetik zu machen und den dan in
einen Pointer zu casten. Und der geladene Funktionspointer wird wiederum
erst in einen Integer überführt, weiß auch nicht wieso.

Ja. Ich sehe da zwar auf den ersten Blick nichts, was wirklich schlimm wäre
(man kann und darf sowas in Lowlevel-Code durchaus machen, aber bitte nur wo
wirklich nötig!), aber sowas erhöht leicht die Chancen, daß der Optimizer
doch eine andere Meinung hat, was gemeint war.

Und nur am Rande verstehe ich auch nicht, warum immer jedermann seine
eigenen typedefs a la "u32" und "vu32" verwenden muss. Wahrscheinlich
auch noch irgendwo ein "#define TRUE 1", statt dass die Leute einfach
stdint.h> und <stdbool.h> verwenden :-/

Immer noch besser als
#define TRUE 0
#define FALSE 1

mit passenden Abfragen (if (var == TRUE)) überall

Sieht aber beides danach aus, als ob der GCC einfach nur seine
Freiheitsgrade verwendet hat.

Ja.

cu
Michael