Nie jestem pewien, co pamięciowy środki, ale co stos wywołań jest informacją jest to, że nie można w wiarygodny sposób zgłosić wartość Instrumentu argumenty.
Rozważmy następujący program:
procedure Foo(Bar: Pointer);
asm
xor eax,eax
end;
begin
Foo(nil);
end.
Wkrocz Foo
. Kiedy to zrobić stos wywołań wygląda to w 32 bit:
Project1.Foo(nil)
Project1.Project1
:76f5337a kernel32.BaseThreadInitThunk + 0x12
:775b92e2 ntdll.RtlInitializeExceptionChain + 0x63
:775b92b5 ntdll.RtlInitializeExceptionChain + 0x36
a to z 64-bitowym:
Project1.Foo(nil)
Project1.Project1
:00000000772959CD ; C:\Windows\system32\kernel32.dll
:00000000773CB981 ; ntdll.dll
Następnie krok nad pierwszym wierszu Foo
. Teraz stos wywołań wygląda to w 32 bit:
Project1.Foo(???)
Project1.Project1
:76f5337a kernel32.BaseThreadInitThunk + 0x12
:775b92e2 ntdll.RtlInitializeExceptionChain + 0x63
:775b92b5 ntdll.RtlInitializeExceptionChain + 0x36
a to z 64-bitowym:
Project1.Foo(Opt.out)
Project1.Project1
:00000000772959CD ; C:\Windows\system32\kernel32.dll
:00000000773CB981 ; ntdll.dll
Co debugger jest informacją jest to, że argumenty przybył w rejestrach. Nie ma kontroli nad tym, co robisz z rejestrami po wykonaniu funkcji asm. W związku z tym odmawia próby raportowania wartości argumentów.
Jeśli przełączysz się na kompilator 32-bitowy i zmienisz konwencję wywoływania tak, aby argumenty pojawiały się na stosie, a nie w rejestrach, zachowanie jest inne. W tym scenariuszu debugger czuje się pewnie, że zgłasza wartości argumentów, ponieważ uważa, że nie zamierzasz wyrzucać stosu.
W wersji 32-bitowej, która została wyjaśniona za pomocą ???
. Dość dlaczego tekst w wersji 64-bitowej nie jest znany, ale jego znaczenie jest jasne.
"Zoptymalizowane"? –
@Uli To prawdopodobnie za pieniądze. W przykładzie w pytaniu argumenty nie są dostępne z powodów innych niż optymalizator. Ogólnie jednak optymalizator prawdopodobnie będzie najczęstszą przyczyną niedostępności argumentów. Prawdopodobnie twórcy debuggerów nie widzieli potrzeby bycia bardziej szczegółowym. –