Delphi 12.1p1 Assembler debuggen nicht mehr möglich?

[himitsu]

Moin Moin,

früher hatte ich eher das Problem, dass ich schwer aus dem Assembler wieder raus kam, in den Quellcode,
aber jetzt hab ich das Problem andersrum, also dass es ständig zurück in den Quellcode springt, ohne dass ich es will.

Im Grunde wollte ich schauen ob und wann Delphi bei den Custom-Managed-Records das Standardverhalten ausführt und wie dazu die neuen Operatoren arbeiten.
Speziell beim Assign, hatte musste ich das genauer wissen.

Delphi 12.1 mit Patch 1
Neue Win32-VCL-Anwendung
der Dreck bezückglich DebugDCUs ist ja inzwischen immernoch standardmäßig aktiv.
und die beiden markierten Haltepunkte setzen (F5)

Delphi-Quellcode:

implementation

{$R *.dfm}

type
  TTest = record
    FInt: Integer;
    FStr: string;
    class operator Initialize(out Dest: TTest);
    class operator Finalize(var Dest: TTest);
    class operator Assign(var Dest: TTest; const [ref] Src: TTest);
  end;

class operator TTest.Initialize(out Dest: TTest);
begin
  Dest.FInt := 123;
  Dest.FStr := 'abc';
end;

class operator TTest.Finalize(var Dest: TTest);
begin
  Dest.FInt := 0;
  Dest.FStr := '';
end;

class operator TTest.Assign(var Dest: TTest; const [ref] Src: TTest);
begin
  Dest.FInt := Src.FInt;
  Dest.FStr := Src.FStr;
end;

procedure Test;
var
  A, B: TTest;
begin
  A.FInt := 456;
  A.FStr := 'def';
  B := A;  {HALTEPUNKT}
  if B.FInt = 0 then;
end;

procedure TForm1.FormCreate(Sender: TObject);  // Form1.OnCreate ;)
begin
  Test;  {HALTEPUNKT}
  Test;  {HALTEPUNKT}
end;

end.

* [F9] bis zum Haltepunkt im FormCreate
* Strg+Alt+C -> ins Assembler
* dann [F7]
* OK, hier nur ein CALL und es landet beim BEGIN der Test-Ptozedur, aber im Pascal.
* erneut Strg+Alt+C
* gut, es ist immernoch direkt am Anfang und der Code für die Initialisierung der lokalen Variablen ist noch nicht durch
* [F7]
* so, jetzt müsste ich den Assembler eigentlich mit [F7] mindestens Zeilenweise bis zum CALL kommen
* aber NEIN, ich lande wieder beim BEGIN der TEST-Prozedur
* Strg+Alt+C und es ging zum Glück doch bloß den einen ASM-Befehl
* wieder [F7], zurück im Pascal, immernoch beim BEGIN ... Strg+Alt+F7 und war doch bloß der eine ASM-Befehl

Ist das bei euch auch so?
Kann noch nicht sein ... beim ersten ASM-Befehl einer Zeile wäre es schon OK, aber die dazwischen

Das sind hier 17 ASM-Befehle ... bei jedem müßte ich hin und her,

Ganz pervers wird es beim [F8], dann sollte es nur den CALL abarbeiten und in die nächste Zeile,
aber MANCHMAL überspringt es nicht nur den CALL, sondern stoppt erst beim nächsten Haltepunkt.

Und beim Strg+F2 (Debuggen beenden), schließt Delphi einfach so bösartig mein, nicht automatisch, sondern von MIR manuell geöffneten CPU-Tab.




Ach ja, zu Beginn werden die beiden Variablen A und B initialisiert,
der FInt ist nicht initialisiert (Random), der String aber schon, also wie erwartet ... deswegen ja das TTest.Initialize,
aber ich hätte erwartet, dass vor dem Aufruf der Standard-Code vom delphi kommt, welcher den String initialisiert (NIL).
Hab gerade das Gefühl, als wäre er im BEGIN meiner Initialization-Prpzedur ... sicher bin ich mir noch nicht ... aber irgendwo muß das NIL sich ja verstecken (hoffe ich).

Beim Assign scheint das standardmäßige System.CopyRecord bzw. System.MoveRecord,
oder ein einfacher Register-Kopieren oder System.Move (für einfache Records ohne Managed-Types),
garnicht ausgeführt zu werden und man muß alles manuell machen.
Was passiert wohl, wenn man faul ist .... ähhhhh, ich meine auf Nummer sicher gehen will .... und Dest := Src; macht?
Nja, so weit bin ich noch nicht, da das Debuggen keinen Spaß macht und ich noch Stunden benötige, bis ich an der Stelle bin, weil mit vorher alle Finger weh tun.

[jaenicke]

Nein, das ist bei mir nicht so. Ich bleibe im Assemblercode. Kann es sein, dass du Parnassus Parallel Debugger installiert hast? Der verursacht nämlich genau diesen Mist.

[himitsu]

maaaaaaaaaaaa

[himitsu]

OK, dann hab ich nun erstmal endlich Klarheit, was diese Operatoren wirklich machen.

Delphi-Quellcode:

procedure Test;
var
  A, B: TTest;
begin
  
end;

Normal sind hier im BEGIN und END (wobei der Debugger in der CPU-Ansicht behauptet es wäre im BEGIN) die Standartbehandlungen für Managed-Typen, wie String, DymArrays, Interfaces und Variants.
"einfache" Typen werden hier ja bekanntlich nicht initialisiert.

Achtung, ein Result (Managed-Type) von aufgerufenen Funktionen sind in Wirklichkeit als VAR-Parameter implementiert, mit einer automatischen lokalen Variable.
Drum ist z.B. ein function Test: string; initialisiert, aber nicht dort, wo man es denkt, also nicht in der Funktion, sondern beim Aufrufer,
weswegen z.B. Aufrufe in Schleifen sich echt witzig auswirken.
Und das ohne, dass der Compiler hier eine Warnung ausgibt, von wegen "Result sei nicht initialisiert", denn es ist das ja.

Delphi-Quellcode:

function Test: string;
begin
  Result := Result + '*';
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  for var i := 1 to 3 do
    ShowMessage(Test);
end;

Hier kommt * , ** und *** raus, anstatt drei Mal * .


PS: Boolean-Result werden scheinbar seit einer Weile mit False initialisiert, wohl weil es zu viele Entwickler gab, welche sämtliche Warnungen ignorieren.
Auch wenn ich diese Initialisierung nirgends finde.
[EDIT] Nein, es ist doch Zufall, dass es "meistens" False war.
Weiter siehe https://www.delphipraxis.net/215251-...ialisiert.html [/EDIT]



Bei einem Record mit den neuen Managed-Operatoren, befindet die sich Standard-Initialisierung im BEGIN des Operators.
Da, wo die Record-Variable deklariert ist, gibt es also nur noch den einen CALL.

Ebenso befindet sich die Standard-Finalisierung im END des Finalize-Operators, anstatt im END bei der Variablen-Deklaration.

Beim Assign-Operator wird garnichts kopiert und man muß ALLES selbst machen, für jedes Feld einzeln.
Dest := Src; , sowie RecordCopy oder ArrayCopy (mit Länge 1) ergeben leider Endlosschleifen, da sie den Operator aufrufen.
-> Hier werde ich demnächst einen FeatureRequest erstellen, mit der Bitte innerhalb des Operators so zu tun, als gäbe es den Operator nicht.

War ursprünglich davon ausgegangen, dass der AssignOperator auch im oder vor dem BEGIN das Standardverhalten hat, was ich in meinem Anwendungsfall aber nicht gebrauchen konnte und es somit für mich eigentlich vollkommen OK ist, wobei ein Dest := Src; uns dennoch das Leben erleichtern könnte und Fehlern vorbeugen könnte, wenn der Record irgendwann um neue Felder erweitert wird.
Bisher hatte ich in meinen Records zufällig nur managed Typen oder Pointer und Diese mußte ich sowieso manuell kopieren, inkl. manueller Referenzzählung.