DLL debuggen

[himitsu]

Neee nee, das war das, wo niemand auch nur erwähnen durfte, dass es eigentlich Delphi hieß.

AppBuilder


Nur kurz vor Veröffentlichung, fiel auf, dass bereits etwas so hieß.
Und weil niemandem was Besseres einfiel, blieb der interne Entwicklungsname bestehen.

[Sinspin]

Es gibt Spuren in der BDS.exe die darauf hindeuten dass zumindest das Lizenzmodul in Pascal geschrieben ist.
Das sagt aber noch nix über die IDE und den Compiler.
Ich habe auch schon in C geschriebene libs direkt in meine exe gelinkt um keine dll mitliefern zu müssen.

Der C++Builder verwendet die gleichen Klassennamen wie Delphi, das ist somit kein Beweis.
Es ist also gut möglich eine Delphi Hülle mit C/C++ Füllung vor der Nase zu haben.
Ich würde mich freuen wenn nicht.

[jaenicke]

Es wurde mehrfach betont, dass Delphi in Delphi geschrieben ist. Wäre das geändert worden, wäre solch ein Cut sicher auch aufgefallen.

[Stevie]

Die IDE ist eine VCL Anwendung, die Compiler sind in C/C++ geschrieben.

[himitsu]

Ja, ich hatte in einem Stacktrace auch schon TurboPascal-Units, welche sich im Win32-Compiler immernoch verstecken, oder war's der Debugger.

[himitsu]

So, also in 12.0 hat sich das Debuggen von EXE+DLL nicht verbessert. (im Momment noch das Gefühl, es ist schlimmer ... also innerhalb der zweiten Stunde)

[freimatz]

Danke für den Hinweis.

[Sinspin]

Zitat von himitsu:

So, also in 12.0 hat sich das Debuggen von EXE+DLL nicht verbessert. (im Momment noch das Gefühl, es ist schlimmer ... also innerhalb der zweiten Stunde)

Ein Glück dass das nicht auch noch anders ist bei jeder Version.
Ich bin glücklich dass es mit 11 besser funktioniert als mit Rio wo alle paar Runden die IDE im Eimer ist weil sie sich selber dem RAM zufüllt.

Die Pfadangaben für die Host exe sind in meinem Fall zumindest kein Grund mich aufzuregen
Habe mir alles nötige drum rum programmiert als After Build Events um mein Host Programm bekommt einen Parameter damit es versteht das ich debugge und die Pfade alle falsch sind.

[himitsu]

Nee, die IDE ist zumindestens seit 10.2 beim Compilieren nicht mehr verreckt.
In XE mußte ich die Projektgruppe in 2-4 Teilen kompilieren, sonst krachte alles mit OutOfMemory, wenn zuviele Projekte auf einmal.

Wenn ich die DLL debugge, egal ob die EXE vorher neu kompiliert oder nicht, hab ich in D12 jetzt zuverlässig immer

Zitat:

Thread-Start: Thread-ID: 17328. Prozess Scripting.exe (8064)
Prozessstart: C:\Develop\ActiveScripting\Win32\Debug\Scripting.e xe. Basisadresse: $00EC0000. Prozess Scripting.exe (8064)
Modul laden: Scripting.exe. Ohne Debug-Infos. Basisadresse: $00EC0000. Prozess Scripting.exe (8064)
Modul laden: ntdll.dll. Ohne Debug-Infos. Basisadresse: $77AA0000. Prozess Scripting.exe (8064)

In der 11.3 war es ab und an mal so, dass da auch die Debuginfos geladen wurden und ich EXE sowie DLL gleichzeitig debuggen konnte.

Die Prozeduren mit StackFrame findet er noch, aber dann steht nur mehrmals der EXE-Name im Stacktrace, anstatt der Prodzedurnamen.

[himitsu]

Kennt sich irgendwe gut mit dem Debuggen und den Einstellungen für DebugInfos aus?


Der einfache Fall geht ja inzwischen "öfters mal".

aber ich wollte hier nun in D11 das auch endlich mal zum Laufen bringen (wir suchen grade in pgDAC einen Fehler).
* Delphi sagt es würde die Debuginfos laden -> Modul laden: dac150.bpl. Enthält Debug-Infos. Basisadresse: $016B0000. ...
* aber weder im Stacktrace noch in den Units ist davon was zu sehn (so als wenn er sie dann nicht benutzen würde)
Sowohl in XE, als auch in 11.3 will das einfach nicht.
Es ist auch egal ob interne oder externe TDS (auch RemoteDebug noch aktiviert gehabt).


* FremdKomponenten werden mit FinalBuilder kompiliert -> Delphi-Action, also DCC32
* eigene BPL/DLL/EXE wurden in XE auch mit Delphi-Action und Eurekalog kompiliert, also ECC32 zu DCC32
* eigene BPL/DLL/EXE werden in 11.3 nun mit MSBuild kompiliert -> intern DCC32 und im AfterBuildScript der ECC

Bei den eigenen Projekten BPL/DLL/EXE funktioniert es in 11.3 nun recht gut (in XE mußten BPLs nochmal im Delphi kompiliert werden, damit DebugInfos funktionierten ... doppelte Configs und im FB mit Fehlern/Unterschieden)

Aber bei den FremdKomponenten bekomm ich es einfach nicht zum Laufen, dass ich Diese debuggen kann.
Es macht auch keinen Unterschied, ob deren Projekte in der geladenen Projektgruppe drin sind.


Früher wurden viele Packages wild über Suchpfade geholt ... inzwischen alles im EXE-/Arbeitsverzeichnis (Testsystem so wie auch bei den Kunden)
vor allem da XE und 11 parallel sich mit gleichnamigen Dateien in den Suchpfaden in die Quere kam.