If the RTL is compiled with optimization then same functions may not
have a stackframe. Of course that is intended. But...
Within the list of those is at least one (probably both of the following:
Procedure fpc_assert(Const
Msg,FName:Shortstring;LineNo:Longint;ErrorAddr:Pointer); [Public,Alias :
'FPC_ASSERT']; compilerproc;
begin
if pointer(AssertErrorProc)<>nil then
AssertErrorProc(Msg,FName,LineNo,ErrorAddr)
...
Procedure AssertErrorHandler (Const Msg,FN : ShortString;LineNo:longint;
TheAddr : pointer);
...
S:=Msg;
Raise EAssertionFailed.Createfmt(SAssertError,[S,Fn,LineNo]) at
get_caller_addr(theAddr), get_caller_frame(theAddr);
This leads to get_caller_addr/get_caller_frame getting the address and
frame of the wrong function.
Instead of the function containing the assert, they will get the caller
of that function.
This is unconvincing if debugging.
I was wondering what the options are? Not even sre if that really is due
to the missing frame
the code calling ASSERT
006F30AB 55 push %ebp // ErrorAddr:
006F30AC b969030000 mov $0x369,%ecx
006F30B1 baf8478000 mov $0x8047f8,%edx
006F30B6 b8c8498000 mov $0x8049c8,%eax
006F30BB e800acd1ff call 0x40dcc0 <fpc_assert>
ErrorAddr is the frame of the function calling assert?
Then why get_caller_addr/get_caller_frame ?
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
