GDB funktioniert, Eclipse nicht.

[Martin R. (rogi1)]

Hallo,

Ich möchte im ersten Schritt mit GDBStub.h und im nächsten schritt mit 
esp-Prog einen ESP8266 debuggen.

Ich habe es geschafft, auf Windows, mit Eclipse, mit ArduinoCore via 
CommandPrompt anzuhalten, indem ich #include <GDBStub.h> und 
gdbstub_init() hinzufüge.

Der Befehl dazu lautet:
xtensa-lx106-elf-gdb.exe

Die Startparameter sind:
set remote hardware-breakpoint-limit 1
set remote hardware-watchpoint-limit 1
set remote interrupt-on-connect on
set serial baud 115200
target remote \\.\COM4

Ich habe dafür das "remote target" abgeschaltet und die Verbindung in 
den Startparameter direkt angegeben.
Es war mir nicht möglich, die Com Verbindung über den "Remote Target" im 
Eclipse direkt einzustellen, das führte zu einem Fehler. Kann mir jemand 
sagen woran das liegen könnte?


Das Debugging startet nun, aber es bleibt nicht wie beim debuggen 
gewohnt stehen. Eigentlich sehe ich gar nicht viel.
Komisch, die GDB Console beklagt ein fehlendes File, welches in diesem 
Projekt gar nicht existiert, sondern in einem anderen testprojekt, 
welches ich erstellt haben.

Ich habe bereits
- Eclipse neu gestartet
- neue Debug Config gemacht
- mehrmals überprüft, ob ich vielleicht eine falsche elf Datei oder 
anderes angegeben habe....
- versucht, so lange nach oben zu springen, um irgendwie zu meinem Code 
zu gelangen
Könnt ihr mir sagen, warum das Programm nicht wie es sollte stoppt oder 
was ich probieren könnte?


Ich habe einen Screenshot angehängt, damit du dir ein Bild machen 
kannst.

lg

[Martin R. (rogi1)]

Ich habe Neuigkeiten:

Grundsätzlich funktioniert das Deduggen in Eclipse, über die 
Debug-Console konnte ich einen Brakepoint setzen, gdb hält dort an, und 
ich kann mit Step-Over an die nächste Zeile Springen, dass das 
funktioniert, sehe ich aber nur, wenn ich Eclipse in den "instruction 
stepping mode" schalte. Dann sieht man auch die Codezeile markiert. .. 
aber halt eben nur in den Assembler-Codes.

Ich vermute, dass Eclipse nicht erkennt, welches Sourcefile zu dem 
elf-File gehört.
Kann mir jemand sagen, wie ich weiter vorgehen könnte um den Fehler zu 
finden?

Im Bild sieht man das funktinierende "Assambly stepping" und die 
Commands vom GDB.

[Stefan F. (Gast)]

Hast du eventuell ohne Debug Infos compiliert?

Mit welchen Optionen wurde der Compiler aufgerufen?

[Martin R. (rogi1)]

Hallo, Die Arduino-Core Umgebung sollte automatisch mit den Debug-Infos 
compilieren.

Der Debugger funktioniert, nachdem ich in der Debugging Konfiguration 
den Pfad der Source-Dateien explizit angegeben habe, was doch etwas 
seltsam ist, da Eclipse wissen sollte, wo die Sourcen des Projektes 
sind.

Leider ist das Debuggen der Umgebung noch alles andere als komfortabel, 
ich werde das Thema weiter verfolgen und eventuell berichten.

[Stefan F. (Gast)]

Martin R. schrieb:
> Die Arduino-Core Umgebung sollte automatisch mit den Debug-Infos
> compilieren.

Genau: sollte. Ist es denn auch so? Wenn irgend etwas nicht 
funktioniert, prüft man vernünftigerweise zuerst alle Annahmen, die man 
getroffen hat. Denn in den meisten Fällen steckt genau dort die 
Fehlerursache.

> Der Debugger funktioniert, nachdem ich in der Debugging Konfiguration
> den Pfad der Source-Dateien explizit angegeben habe

Eclipse ist ein Programm, der Compiler ein anderes und der Debugger noch 
ein anderes. Diese drei Programme werden jeweils unterschiedlich und 
individuell konfiguriert. Eigentlich sollte ein Plugin der IDE diese 
Konfigurationen synchron halten. Aber leider kann man sich nicht darauf 
verlassen. Das klappt nicht einmal bei Java Projekten sauber.

Eclipse ist nicht das geniale Wunderwerk, dass es nach außen zu sein 
scheint. Im Gegenteil, Eclipse ist meiner Meinung nach die schlechteste 
IDE, die ich je gesehen habe. Ursache dafür ist meiner Meinung nach der 
Versuch, eine Eierlegende Wollmilchsau zu bauen. Eclipse ist nur 
deswegen in aller Munde, weil sich viele Leute wirklich gute IDEs nicht 
leisten konnten/wollten.

[Martin R. (rogi1)]

> Ist es denn auch so? Wenn irgend etwas nicht
> funktioniert, prüft man vernünftigerweise zuerst alle Annahmen, die man
> getroffen hat. Denn in den meisten Fällen steckt genau dort die
> Fehlerursache.

Ja, logisch, interessanter wäre doch an dieser Stelle wie, die 
Einstellungen von Eclipse sind an dieser Stelle recht überschaubar. Ich 
stamme aus der c# Welt, c-compiler und Eclipse sind mir noch recht 
unbekannt.

> Eigentlich sollte ein Plugin der IDE diese
> Konfigurationen synchron halten.

interessant! wusste ich nicht.

[Bernd K. (prof7bit)]

Das erste was mir auffällt ist daß alles voller gelber und roter 
Wellenlinien ist, Du mußt der IDE erst mal alle Includepfade für dieses 
Projekt mitteilen so daß Eclipse in der Lage ist alle Dateien überhaupt 
erst mal zu finden. Vorher würde ich gar nicht erst anfangen übers 
Debuggen nachzudenken.

[Bernd K. (prof7bit)]

Stefan F. schrieb:
> Eclipse ist ein Programm, der Compiler ein anderes und der Debugger noch
> ein anderes. Diese drei Programme werden jeweils unterschiedlich und
> individuell konfiguriert. Eigentlich sollte ein Plugin der IDE diese
> Konfigurationen synchron halten.

* Entweder konfiguriert man es in Eclipse und Ecplipse ruft dann 
Compiler und Linker genau so auf wie es in Eclipse konfiguriert ist, in 
dem Fall muss man gar nichts synchron halten,

* Oder im anderen Fall konfiguriert man es in seinem 
Build-Script/Makefile/Whatever und schaltet in Eclispe den 
Build-Output-Parser ein, dann synchronisiert sich Eclipse immer 
automatisch bei jedem Build indem es die Compileraufrufe parst.

In beiden Fällen braucht man kein extra Plugin dafür, man muss das 
Projekt nur richtig konfigurieren, dann geht das alles problemlos und 
zuverlässig.

[Stefan F. (Gast)]

Bernd K. schrieb:
> In beiden Fällen braucht man kein extra Plugin dafür

Eclipse kann ohne Plugins weder mit GCC noch mit Makefiles etwas 
anfangen. Irgendein Plugin wird wohl dahinter stecken.

[Bernd K. (prof7bit)]

Stefan F. schrieb:
> Eclipse kann ohne Plugins weder mit GCC noch mit Makefiles etwas
> anfangen. Irgendein Plugin wird wohl dahinter stecken.

Diese Funktionalität ist Bestandteil von CDT und das wird man ja wohl 
installiert haben wenn man C oder C++ mit Eclipse entwickelt, sonst 
könnte es nicht mal die Syntax highlighten. Das kann man auch im 
Komplettbundle "Eclipse for C/C++" herunterladen so wie das die meisten 
tun wenn man keine Lust hat CTD nachträglich in einem anderweitig 
genutzten Eclipse zu installieren.

[Stefan F. (Gast)]

Bernd K. schrieb:
> Diese Funktionalität ist Bestandteil von CDT und das wird man ja wohl
> installiert haben

Ja. Was ich eigentlich sagen wollte war, dass sich ein Plugin um die 
Konfiguration vom GDB kümmern sollte - nicht das ein Plugin fehlt.

[Bernd K. (prof7bit)]

Stefan F. schrieb:
> Ja. Was ich eigentlich sagen wollte war, dass sich ein Plugin um die
> Konfiguration vom GDB kümmern sollte - nicht das ein Plugin fehlt.

Also ich musste in den Debugeinstellungen noch nie irgendwelche Pfade 
extra konfigurieren, er findet alle Quellen des aktuelle Projekts von 
selbst.

Aber OP hat ja offensichtlich ein Fremdprojekt importiert und nutzt 
nicht Eclipse um damit zu entwickeln, deshalb schlug ich ja vor wenn er 
ernsthaft Eclipse nutzen will muss er auch den ganzen Weg gehen und das 
Projekt und alle seine Einstellungen und Dateien und Pfade Eclipse 
korrekt bekannt machen, auf die eine oder andere Weise. Dann klappt das 
wahrscheinlich auch.

Ich selbt nutze Eclipse-CDT (vanilla, nicht gebrandet) vorwiegend für 
Makefile-Projekte (also hab ich den Build-Output_scanner eingeschaltet 
[und für arm-none-eabi-gcc konfiguriert (wichtig!)]) damit Eclipse die 
Pfade erkennt (das ist auch mein Lieblingsmodus denn so hab ich alle 
Konfiguration immer schriftlich und an einer zentralen Stelle im 
Makefile und kann genausogut auch mal auf der Konsole bauen falls nötig) 
und dann flutscht das praktisch alles immer wie von selbst. Das einzige 
zusätzliche Plugin das ich außer CTD noch habe ist GNU-MCU.


Bekannte Schwächen:

* BOP muss für jedes Projekt erneut erstmalig konfiguriert werden damit 
er den Compileraufruf erkennt wenn es ein cross gcc ist weil das 
default-Pattern von Eclipse da nicht matcht.

* Nach dem Import eines solchen Projekts auf nem neuen Rechner muss man 
nach dem ersten Öffnen nochmal git reset --hard machen weil Eclipse beim 
Import an der Konfigdatei für den BOP rumschraubt (Bug, bereits 
gemeldet), danach bleibts dann OK.

* Windowsnutzer haben zusätzlichen Stress für die ganzen Toolpfade bis 
alles läuft, unter anderen OS ist das allerdings kein Problem.

[Stefan F. (Gast)]

Bernd K. schrieb:
> Dann klappt das wahrscheinlich auch.

Ja, denke ich auch

[Martin R. (rogi1)]

Wenn wir schon dabei sind, Eclipse zu zerlegen:

Ich habe jetzt die ESP32 Targets hinzugefügt, und ein Demoprojekt für 
esp32 gestartet. Eclipse möchte aber das Projekt mit dem Compiler aus 
esp8266-Ordner compilieren, und findet dann auch noch .h Files nicht - 
Logisch, wenn das falsche target compiliert wird...

Ich habe im Launch-Target das NodeMcu angegeben. Unter Connection steht 
esp8266, wenn ich das auf esp32 ändere, steht nach erneutem Öffnen der 
Konfiguration für die Launch-Tagets wieder esp8266 drinnen.

Ein neustart der IDE hilft nicht.

Woher weiß Eclipse mit Arduino core, um welchen Controller es sich 
handelt, und wo der gcc bzw. die Libs dazu liegen?

[Bernd K. (prof7bit)]

Eine Alternative wäre vielleicht vscode wenn es darum geht Arduino ohne 
dessen "IDE" zu machen, das schont die Nerven vielleicht besser wenn 
Eclipse  mit einem auf Kriegsfuß steht.

Und zum reinen Debuggen geht vielleicht auch schon sowas wie DDD oder 
eins der anderen gdb GUI-Frontends, da muß man auch nicht immer gleich 
das volle Eclipse aufmarschieren lassen, insbesondere wenn man eh nicht 
plant es auch zum Coden zu benutzen.