Zitat von
mse1:
Zitat von
schöni:
Ich brauche: Name der aktuell untersuchten Quelldatei, Zeilennummer, Name der Funktion/Prozedur/Methode und evtl. die aktuelle Adresse im Binärcode.
In GDB/MI.
Zur Kommunikation mit gdb gibt es mehrere Möglichkeiten. Eine erste
IDE (die ich nicht erwähnen darf) benützt die Library libgdb, zwei andere
IDE's (die ich ebenfalls nicht erwähnen darf) benutzen pipes zur gdb Applikation. Ersteres ist problematisch, da libgdb nicht mehr zum Lieferumfang der gdb Distribution gehört.
Am liebsten wäre mir auf der
IDE Seite ein einheitliches Interface, das so beschaffen ist, das ich später auch einen Embarcadero Debugger anschließen kann, wenn ich mit einem Delphi Compiler
VCL Code übersetzt habe. Dann könnte mir einfallen, die
IDE auf Visual C++ zu erweitern und brauche vielleicht einen Microsoft Debugger, wegen der unterschidlichen Formate der Debuginformationen.
Solch einheitliches Interface hab ich für zukünftige Versionen der
IDE eh geplant und zwar so, das ich, während ich jetzt Klassen anspreche, die mir meine Aufgabe erledigen, stattdessen ein geeignetes Interface baue und dann anspreche, wobei die Implentation als Plugin realisiert wird. Mehere .dll mit der Funktionalität. Kommt aber erst später, wenn die Basisfunktionen der
IDE alle drin sind.
Gibt es dieses einheitliche Debuggerinterface oder ist es da geschickter, 3 verschidene Interfaces zu bauen? Die Erkennung des aktuell auszuwählenden Interfaces könnte über eine Kennung in der .exe erfolgen, ob dwarf, omf oder coff Format. Oder an Hand des Compilernamens. fpc.exe -> dwarf; gcc.exe->dwarf; bcc*.exe->omf; dcc*exe,oxygen.exe->omf vcc.exe->omf.
Warum darfst Du die IDEs nicht erwähnen? Das Du mir davon den Quellcode nicht unbedingt zugänglich machen darfst, verstehe ich. Aber die
IDE verschweigen?
Mit Pipes hab ich experimentiert. Problem ist dort, das ich bei Informationsaustausch nicht weiß, was für ein Ereignis da den Empfang von Daten signalisiert. Sobald ich aber Windows Messages verwende, bin ich Plattformabhängig.
Habe dann ein
DP Beispiel zu named pipes mit Formularen angeguckt. Da kann ich einen Datensatz senden. Der Emfänger sinalisiert den Emfang der Daten jedoch durch ButtoClick. Ich brauch aber ein Ereignis, das den Datenempfang signalisiert und bei Auftreten des Ereignisses die Daten anzeigt.
Gibt es da was in den Tiefen der
VCL?
Dann bin ich auf WM_CopyData gestoßen, was aber wieder eine Windows Botschaft ist und damit plattformabhängig.
Ich könnte mir vorstellen, das die Namenskonvention für Pipes plattformübergreifend gültig ist. Aber das Öffnen der Pipe? Es ließe sich natürlich eine Schnittstelle mit eigenen Aufrufroutinen- oder Methoden bauen.
Zitat:
Habe deshalb das Beispielprojekt "debugtest.lpr" im Verzeichnis "<lw:/Programme/lazarus/debugger/test"
Dort erhalte ich die
Exception EConverterror, deren Stelle ich im Quelltext noch nicht gefunden habe. Der Fehler liegt nicht im Testprogramm, das vom Debugger untersucht wird, sondern definitiv im Debuggerinterface selber.
Ich würd gerne diese Teil als Debugserver verwenden, ...
Dieser Code ist möglicherweise
GPL was bedeutet, dass du den gesamten Quelltext veröffentlichen musst, falls du dein Produkt weitergibst. Möglicherweise auch den Code der Delphi units was durch die Delphi Lizenz verboten wird.
Das ist natürlich auch wieder
OT, sorry.[/quote]
So weit wie ich die
GPL verstanden habe, dürfte ich nur verpflichtet sein, den Quelltext der
GPL Teile weiter zu geben. Das wäre dann das angepasste Programm des Debuggerbeispiels. Für den Rest dürfte die Nennung einer Bezugsquelle ausreichen. Dabei berufe ich mich auf Lazarus 0.9.22, da dort der aktuelle EConverterror nicht aufgetreten ist, den ich in der 0.0.24er Lazarus Version erhalte, sobald ich nach der Initialisierung des Debuggers den ersten Programmschritt ausführe.
Quelltext den ich dann auf jeden Fall weitegeben muss, wäre wie gasgt mein verändetes Programm. Konkret betrifft das die
Unit DebugtestForm. Werde wohl dann das geänderte Programm samt seinem Quellcode der
IDE beilegen. Zum erneuten Übersetzen sind dann halt noch die von mir nicht veränderten Dabuggerunits nötig, die dann nicht Bestandteil meiner
IDE werden, sondern im Lazarus Projekt zu finden sind.
Werde sehen, welchen Workaround ich für den EConvertError finde. Vielleicht sollte ich mir Lazarus 0.0.22 wieder installieren. Dann müsste ich auf jeden Fall nur das von mir geänderte Beispielprogramm weiter geben.
Bei der Suche nach dem EConvertError verlangt der Lazarus Debugger nämlich ständig neue .inc Dateien, die ich dann mühsam suchen muss, um sie ins Projekt einzubinden, damit ich mich zur Fehlerstelle vortasten kann. Eh ich mich da verpflichte diese .inc Dateien mit weiter zu geben, weil da vielleicht Änderungen nötig werden, installier ich mir eheer wieder die vorangegangene Lazarus Version. Mit der gab es den EConvertError nicht. Dann muss ich auch keine geänderten .inc Dateien weiter geben.
Andere Quellen, die ich genutzt habe, hab ich ja nicht verändert und sind daher im Lazarus Projekt einzusehen. Ich weiß, das ich, statt die Quelltexte selber weiter zu geben, auch eine Quelle nennen kann, wo die Quelltexte zu erhalten sind. Wenn die
IDE nicht Bestandteil von Freepascal wird, werden die von mir nicht veänderten Quellcodes auch nicht zum Übersetzen gebraucht.
Das hier habe ich soeben in der Wikipedia zur
GPL gefunden:
Zitat:
Alle abgeleiteten Programme eines unter der
GPL stehenden Werkes dürfen von Lizenznehmern nur dann verbreitet werden, wenn sie von diesen ebenfalls zu den Bedingungen der
GPL lizenziert werden.
Der Debugserver wäre dann das abgeleitete Programm, das aus dem Testbeispiel hervorgegangen ist. Die
IDE greift darauf nur zu. Das passiert mit Nachrichten. Als .dll einbinden dürfte am Binärformat scheitern. Hab da scon mal Versuchre gemacht. Statisch in die
IDE einbinden klappt somit auch nicht. Habe Versuche sowohl mit LoadLibrary() als auch mit
DLL-Interfaceunit gemacht. Hat beides nicht funktioniert. Und mit Delphi die Debuggerteile übersetzen scheitert an den Unterschieden im Pascaldialikt. So bleibt der Debugserver ein selbständiges Programm, womit ich bei der
IDE weitehin volle Entscheidungsfreiheit bezüglich der Lizenz haben dürfte.
Anders wäre es, wenn ich als Quellcodeeditor den aus Lazarus verwenden würde. Dann wäre auch die
IDE unter
GPL zu stellen.