Tweet
Hallo,
ich habe zur Zeit folgendes Problem beim Debuggen von Dll's mit Delphi 6 unter Windows XP Professional.
Für eine Anwendung wurde eine Dll geschrieben, die einige Funktionen auslagert um den Source Code der Anwendung zu minimieren. Desweiteren wird die Dll von einigen C++ Dll's verwendet, um eine Schnittstelle zwischen Delphi und C++ zu erhalten (hierzu verwenden wir auch ein eigens entwickeltes "COM", das als Basis das Star Office IDL/OM verwendet, COM kompatibel). Aber das ist eigentlich nicht so wichtig.
Die Dll exportiert einige Funktionen einfach via stdcall in Ihrer exports Klausel. Diese Funktionen sind "Standard", wie z.B. function Add(a,b : Double) : Double; stdcall;...
Die Funktionen werden mit Hilfe von Prototypen (type foo=function(...): result; stdcall; var ffoo : foo) in der Host Anwendung mit Hilfe von LoadLibrary() und GetProcAddress() geladen und ausgeführt.
Die Dll ist dabei im selben Verzeichnis wie die EXE.
Die Dll wird ganz normal mit Debug Informationen kompiliert (und Debug Dcu's).
Beim Debuggen mit Hilfe einer Host Anwendung werden allerdings keinerlei Breakpoints vom Delphi Debugger angesprochen.
Es hilft nur, die Dll mit Hilfe der Linker Optionen "Include TD32 debug infos" und "Include remove debug symbols" zu kompilieren. Danach muss man noch in der Modulliste (View/Debug windows/Modules) die Funktion "Reload symbol table" aufrufen, damit Delphi die Breakpoints erkennt.
Das Ganze ist auch nochmal gut unter folgenden Artikel beschrieben:
http://groups.google.com/groups?hl=de&threadm=3bfab912_1%40dnews&rnum=5&pre v=/groups%3Fq%3D%252Bdelphi%2B%252B6%2B%252Bxp%2B%252 Bdebug%26hl%3Dde
Da anscheinend bei Borland niemand die Support Anfragen berarbeit, wollt ich hiermal im Forum nachfragen, ob jemand eine "bessere" Lösung hat, da diese doch sehr umständlich ist.
Mit freundlichen Grüßen, Sven Bobrowski
ich habe zur Zeit folgendes Problem beim Debuggen von Dll's mit Delphi 6 unter Windows XP Professional.
Für eine Anwendung wurde eine Dll geschrieben, die einige Funktionen auslagert um den Source Code der Anwendung zu minimieren. Desweiteren wird die Dll von einigen C++ Dll's verwendet, um eine Schnittstelle zwischen Delphi und C++ zu erhalten (hierzu verwenden wir auch ein eigens entwickeltes "COM", das als Basis das Star Office IDL/OM verwendet, COM kompatibel). Aber das ist eigentlich nicht so wichtig.
Die Dll exportiert einige Funktionen einfach via stdcall in Ihrer exports Klausel. Diese Funktionen sind "Standard", wie z.B. function Add(a,b : Double) : Double; stdcall;...
Die Funktionen werden mit Hilfe von Prototypen (type foo=function(...): result; stdcall; var ffoo : foo) in der Host Anwendung mit Hilfe von LoadLibrary() und GetProcAddress() geladen und ausgeführt.
Die Dll ist dabei im selben Verzeichnis wie die EXE.
Die Dll wird ganz normal mit Debug Informationen kompiliert (und Debug Dcu's).
Beim Debuggen mit Hilfe einer Host Anwendung werden allerdings keinerlei Breakpoints vom Delphi Debugger angesprochen.
Es hilft nur, die Dll mit Hilfe der Linker Optionen "Include TD32 debug infos" und "Include remove debug symbols" zu kompilieren. Danach muss man noch in der Modulliste (View/Debug windows/Modules) die Funktion "Reload symbol table" aufrufen, damit Delphi die Breakpoints erkennt.
Das Ganze ist auch nochmal gut unter folgenden Artikel beschrieben:
http://groups.google.com/groups?hl=de&threadm=3bfab912_1%40dnews&rnum=5&pre v=/groups%3Fq%3D%252Bdelphi%2B%252B6%2B%252Bxp%2B%252 Bdebug%26hl%3Dde
Da anscheinend bei Borland niemand die Support Anfragen berarbeit, wollt ich hiermal im Forum nachfragen, ob jemand eine "bessere" Lösung hat, da diese doch sehr umständlich ist.
Mit freundlichen Grüßen, Sven Bobrowski
Comment