 |
Das deutsche QBasic- und FreeBASIC-Forum Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
|
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
kawe
Anmeldungsdatum: 25.03.2012 Beiträge: 41
|
Verfasst am: 28.04.2012, 10:56 Titel: Keine (Win32-) Unterstützung für Insight-Debugger (mehr)? |
|
|
Hallo nochmal,
nachdem ich nun die ersten Gehversuche mit FreeBasic hinter mir habe, wollte ich mich als "gebürtiger Javaner" ein bisschen mit den Debugging-Möglichkeiten auseinandersetzen.
Bei einer compilierten Sprache sind natürlich die Erwartungen erstmal bescheiden, . Also Foren durchsucht - und tatsächlich hier und da was gefunden, .
Habe dann brav versucht, die für FreeBasic unter Windows auf Sourceforge abgelegte Insight-Version (http://kent.dl.sourceforge.net/project/fbc/Tools/GDB_Insight/GDB-Insight-1.0-win32.zip) einzurichten ...
Leider bekomme ich sowohl über FBEdit als auch beim direkten Start von Insight (natürlich nach Komplieren mit Option -g) nur eine Fehlermeldung:
[...] internal-error: read_comp_unit_head: dwarf from non elf file
A problem internal to GDB has been detected, [...]
Bestimmt passen da die Version von FreeBasic und Insight nicht zusammen, oder habe ich da vielleicht noch irgendeine Kleinigkeit vergessen?
Gibt es denn überhaupt eine (unter Windows) funktionierende Debugmöglichkeit (außer Print und DebugView o.ä.)?
lG |
|
Nach oben |
|
 |
MOD Fleißiger Referenzredakteur

Anmeldungsdatum: 10.09.2007 Beiträge: 1003
|
Verfasst am: 28.04.2012, 12:18 Titel: |
|
|
Ich habe nie mit Insight gearbeitet, kann auch nicht sagen, warum die Windows-Version irgendwas von ELF-Dateien (Linux-Binärformat, also quasi eine .exe für Linux) redet.
Versuch doch mal den FBdebugger. |
|
Nach oben |
|
 |
28398
Anmeldungsdatum: 25.04.2008 Beiträge: 1917
|
Verfasst am: 29.04.2012, 21:58 Titel: Re: Keine (Win32-) Unterstützung für Insight-Debugger (mehr) |
|
|
kawe hat Folgendes geschrieben: | Bei einer compilierten Sprache sind natürlich die Erwartungen erstmal bescheiden |
Weil Java nicht kompiliert wird...? |
|
Nach oben |
|
 |
kawe
Anmeldungsdatum: 25.03.2012 Beiträge: 41
|
Verfasst am: 30.04.2012, 14:18 Titel: |
|
|
.. oh Sch***, hatte gerade so eine schöne Antwort erstellt, und am Ende aus Versehen den falschen Knopf im Browser gedrückt ...
Soviel noch mal in "Kürze":
@MOD:
vielen Dank für den Link. Das ist wirklich ein guter Debugger und verdient es meiner Meinung nach, in den offiziellen Downloadbereich des Portals aufgenommen zu werden ... Ich hatte ihn auf Anhieb erstmal nicht gefunden ...
@28398:
Bei interpretierten Sprachen bringt ja der Interpreter von Haus aus schon fast alles mit, was ein Debugger braucht: Kontrolle über den Programmablauf und Speicherstatus, und meist auch bereits Einbettung oder zumindest Kommunikation mit einem Edtor, die wechselseitig die Kontrolle und Nachrichten aneinander abgeben können. Was fehlt, kann der Entwickler meist schon selbst übernehmen ("Illegal Argument?" -*break* - ?x : x= 37 :cont -> und weiter geht's ...). Sogar Codeänderungen und die unabhängige Ausführung zur Laufzeit neu erzeugten Codes sind da ja, naturbedingt, gar kein Problem.
In einer ("echt") kompilierten Sprache wie C/C++ (und eben auch FreeBasic) ist davon erstmal nichts da. Der Compiler muss Extraarbeit machen. Es muss ja quasi erstmal eine Laufzeitumgebung geschaffen werden, die die Programmkontrolle ermöglicht. Das ist, anders als beim Interpreter, eine völlig neue Aufgabe. Diese Aufgabe wird von fbc offensichtlich gut erfüllt, aber:
Was er auch macht - irgend ein Editor muss sich dann auch die (enorme) Extraarbeit machen und die Kommunikation mit dieser fremden Umgebung aufnehmen. Aber Editor und Kompiler sind bis dahin völlig eigene Welten und haben bisher kaum interagiert. Debuggen ist aber komplex und plötzlich muss man eine Art API zum laufenden Programm bedienen. Und dabei ist jeder Kompiler anders und jeder Editor - und das dann auch noch unter verschiedenen Betriebssystemen ...
Kurzum: Letzendlich muss wieder so etwas wie ein Interpreter geschaffen werden. Zeilenweise Abarbeitung bei Kontrolle über das System. Die Kontrolle geht dabei meist nicht so weit wie bei einem Interpreter - dafür muss aber das eigentliche Programmkompilat mit dem Debuggingprozess verwoben werden.
Java (aber auch z. B. .NET-Sprachen, Python (optional) u.v.a.) wird zur Laufzeit *nicht* interpretiert, sondern durchaus kompiliert. Allerdings in einen Code, der nicht vom Prozessor auf einer realen, sondern von einer Laufzeitumgebung in einer vrtuellen Maschine ausgeführt wird (Bytecode). Aus abstrakter Sicht ist dieser Code natürlich für ein Debuggersystem viel optimaler, wenn auch nicht so optimal wie der Quellcode selbst (der aber mehr oder weniger immer aus ihm rekonstruierbar, in jedem Fall mit diesem leicht verknüpfbar ist, wenn man es nicht aktiv verhindert).
Dieser Code muss sich nicht mit Prozessor-Architekturen, Betriebssystemen oder Platformen auseinandersetzen. Und - er wird auf einer (virtuellen) Maschine ausgeführt, die, anders als der reale PC, ja extra dafür gemacht ist, mit ihr zu interagieren.
Das hört sich toll an, ist es auch - aber hat natürlich seinen Preis.
Java ist mehr als eine Sprache. Es ist ein riesiges System geworden, das, bei allem Komfort, in kleineren, insbesondere privaten, Projekten oft keinen Spaß mehr macht. Wie jedes riesige System verschlingt es inzwischen Unmengen an Resourcen zur Selbsterhaltung, reagiert träge und verdirbt einem bei kleinen Aufgaben gehörig den Spaß. Bis man soweit ist, "Hallo Welt!" in der Konsole auszugeben, braucht es schon wirklich viel an Resourcen; aber selbst der Code ist hier vergleichsweise aufwändig. "Hallo Welt!" von der Tastatur *einzulesen*, war bereits die erste größere Herausforderung in meiner Lehrzeit, .
Kurzum: Bei einer "echt" kompilierten, architektonisch offensichtlich C sehr nahe stehenden, nicht kommerziellen, Sprache wie FreeBasic, die auch ständig in der Entwicklung begriffen ist, ist es meiner Meinung nach tatsächlich realistisch, seine Ansprüche an einen Debugger klein zu halten. Kompiler *und* IDE müssen (auf verschiedenen Plattformen) jeweils komplett neue Aufgaben erfüllen und darüber hinaus komplexe Kommunikation zum Programm ermöglichen/leisten. Das meiste davon bringt eine interpretierte Sprache von Haus aus mit. Java ist da schlecht vergleichbar. Wer würde schon ersthaft einen eigenen Debugger für Java schreiben!? Aber das Konzept der "virtuellen Maschine" macht natürlich auch hier vieles einfacher, wenn sie denn erstmal da ist.
Zu meiner Aussage der "bescheidenen Erwartungen" haben mich aber vor allem meine Erfahrungen mit C/C++, Pascal und Assembler inspiriert ... und der Blick auf den Downloadbereich spricht ja auch Bände ...
lG |
|
Nach oben |
|
 |
28398
Anmeldungsdatum: 25.04.2008 Beiträge: 1917
|
Verfasst am: 30.04.2012, 14:50 Titel: |
|
|
kawe hat Folgendes geschrieben: | In einer ("echt") kompilierten Sprache wie C/C++ (und eben auch FreeBasic) ist davon erstmal nichts da. Der Compiler muss Extraarbeit machen. Es muss ja quasi erstmal eine Laufzeitumgebung geschaffen werden, die die Programmkontrolle ermöglicht. Das ist, anders als beim Interpreter, eine völlig neue Aufgabe. Diese Aufgabe wird von fbc offensichtlich gut erfüllt, aber:
Was er auch macht - irgend ein Editor muss sich dann auch die (enorme) Extraarbeit machen und die Kommunikation mit dieser fremden Umgebung aufnehmen. Aber Editor und Kompiler sind bis dahin völlig eigene Welten und haben bisher kaum interagiert. Debuggen ist aber komplex und plötzlich muss man eine Art API zum laufenden Programm bedienen. Und dabei ist jeder Kompiler anders und jeder Editor - und das dann auch noch unter verschiedenen Betriebssystemen ...
Kurzum: Letzendlich muss wieder so etwas wie ein Interpreter geschaffen werden. Zeilenweise Abarbeitung bei Kontrolle über das System. Die Kontrolle geht dabei meist nicht so weit wie bei einem Interpreter - dafür muss aber das eigentliche Programmkompilat mit dem Debuggingprozess verwoben werden.
Java (aber auch z. B. .NET-Sprachen, Python (optional) u.v.a.) wird zur Laufzeit *nicht* interpretiert, sondern durchaus kompiliert. Allerdings in einen Code, der nicht vom Prozessor auf einer realen, sondern von einer Laufzeitumgebung in einer vrtuellen Maschine ausgeführt wird (Bytecode). Aus abstrakter Sicht ist dieser Code natürlich für ein Debuggersystem viel optimaler, wenn auch nicht so optimal wie der Quellcode selbst (der aber mehr oder weniger immer aus ihm rekonstruierbar, in jedem Fall mit diesem leicht verknüpfbar ist, wenn man es nicht aktiv verhindert).
Dieser Code muss sich nicht mit Prozessor-Architekturen, Betriebssystemen oder Platformen auseinandersetzen. Und - er wird auf einer (virtuellen) Maschine ausgeführt, die, anders als der reale PC, ja extra dafür gemacht ist, mit ihr zu interagieren.
Das hört sich toll an, ist es auch - aber hat natürlich seinen Preis.
Java ist mehr als eine Sprache. Es ist ein riesiges System geworden, das, bei allem Komfort, in kleineren, insbesondere privaten, Projekten oft keinen Spaß mehr macht. Wie jedes riesige System verschlingt es inzwischen Unmengen an Resourcen zur Selbsterhaltung, reagiert träge und verdirbt einem bei kleinen Aufgaben gehörig den Spaß. Bis man soweit ist, "Hallo Welt!" in der Konsole auszugeben, braucht es schon wirklich viel an Resourcen; aber selbst der Code ist hier vergleichsweise aufwändig. "Hallo Welt!" von der Tastatur *einzulesen*, war bereits die erste größere Herausforderung in meiner Lehrzeit, .
Kurzum: Bei einer "echt" kompilierten, architektonisch offensichtlich C sehr nahe stehenden, nicht kommerziellen, Sprache wie FreeBasic, die auch ständig in der Entwicklung begriffen ist, ist es meiner Meinung nach tatsächlich realistisch, seine Ansprüche an einen Debugger klein zu halten. Kompiler *und* IDE müssen (auf verschiedenen Plattformen) jeweils komplett neue Aufgaben erfüllen und darüber hinaus komplexe Kommunikation zum Programm ermöglichen/leisten. Das meiste davon bringt eine interpretierte Sprache von Haus aus mit. Java ist da schlecht vergleichbar. Wer würde schon ersthaft einen eigenen Debugger für Java schreiben!? Aber das Konzept der "virtuellen Maschine" macht natürlich auch hier vieles einfacher, wenn sie denn erstmal da ist.
Zu meiner Aussage der "bescheidenen Erwartungen" haben mich aber vor allem meine Erfahrungen mit C/C++, Pascal und Assembler inspiriert ... und der Blick auf den Downloadbereich spricht ja auch Bände ...
|
Okay, konntest du nicht wissen, aber den langen Text hättest du nicht schreiben brauchen Weiß ich natürlich.
Ich wollte nur darauf anspielen, dass Java ebenso kompiliert wird; dass da noch die JVM zwischen liegt und der Bytecode besser zu debuggen ist, weiß ich durchaus
Grundsätzlich treffen aber die gleichen Restriktionen zu, wie auf FB, C oder C++.
Der GDB funktioniert übrigens mit Freebasic bestens, zumindest hat er das früher  |
|
Nach oben |
|
 |
dkl FreeBASIC-Compiler-Entwickler
Anmeldungsdatum: 25.04.2010 Beiträge: 14 Wohnort: Germany
|
Verfasst am: 18.05.2012, 16:25 Titel: |
|
|
Mindestens im 0.23er release hab ich dummerweise MinGW libraries reingepackt die DWARF debug format sections beinhalten. Alte Win32 GDB Versionen kommen damit nicht zurecht, wie auch schon hier bemerkt wurde:
http://www.freebasic.net/forum/viewtopic.php?f=17&t=16206
Mit aktuelleren GDB Version läuft alles, ich glaube allerdings es wäre gut beim nächsten Release darauf zu achten das nur das Stabs Format "enthalten" ist. Und man sollte auch mal nach Insight updates Ausschau halten... |
|
Nach oben |
|
 |
|
|
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
|