Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
 
FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen  RegistrierenRegistrieren
ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin
Zur Begleitseite des Forums / Chat / Impressum
Aktueller Forenpartner:

Keine (Win32-) Unterstützung für Insight-Debugger (mehr)?

 
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Allgemeine Fragen zu FreeBASIC.
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
kawe



Anmeldungsdatum: 25.03.2012
Beiträge: 41

BeitragVerfasst am: 28.04.2012, 10:56    Titel: Keine (Win32-) Unterstützung für Insight-Debugger (mehr)? Antworten mit Zitat

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, zwinkern. Also Foren durchsucht - und tatsächlich hier und da was gefunden, lächeln.
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
Benutzer-Profile anzeigen Private Nachricht senden
MOD
Fleißiger Referenzredakteur


Anmeldungsdatum: 10.09.2007
Beiträge: 1003

BeitragVerfasst am: 28.04.2012, 12:18    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
28398



Anmeldungsdatum: 25.04.2008
Beiträge: 1917

BeitragVerfasst am: 29.04.2012, 21:58    Titel: Re: Keine (Win32-) Unterstützung für Insight-Debugger (mehr) Antworten mit Zitat

kawe hat Folgendes geschrieben:
Bei einer compilierten Sprache sind natürlich die Erwartungen erstmal bescheiden

Weil Java nicht kompiliert wird...?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
kawe



Anmeldungsdatum: 25.03.2012
Beiträge: 41

BeitragVerfasst am: 30.04.2012, 14:18    Titel: Antworten mit Zitat

.. oh Sch***, hatte gerade so eine schöne Antwort erstellt, und am Ende aus Versehen den falschen Knopf im Browser gedrückt weinen ...

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, zwinkern.

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
Benutzer-Profile anzeigen Private Nachricht senden
28398



Anmeldungsdatum: 25.04.2008
Beiträge: 1917

BeitragVerfasst am: 30.04.2012, 14:50    Titel: Antworten mit Zitat

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, zwinkern.

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 zwinkern 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 grinsen
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 lächeln
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
dkl
FreeBASIC-Compiler-Entwickler


Anmeldungsdatum: 25.04.2010
Beiträge: 14
Wohnort: Germany

BeitragVerfasst am: 18.05.2012, 16:25    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Allgemeine Fragen zu FreeBASIC. Alle Zeiten sind GMT + 1 Stunde
Seite 1 von 1

 
Gehe zu:  
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.

 Impressum :: Datenschutz