Hi all,

I've just pushed a commit that changed the stack-unwinding logic for FpDebug.

What is new is that when the executable includes Call Frame Information (CFI) as specified by the Dwarf-format and CFI is available for the a certain location, the CFI is used to unwind the stack. (x86_64 and i386 only)

Note however, that the CFI generated by FPC is not always correct, but in those cases is should fallback to the old implementation.

In principle things could only get better. But if not, please tell me.

Regards,

Joost.

Great news, thank you Joost. This should decrease the amount of code memory that needs to be scanned when building a stack trace - a boost particularly for remote debugging.

On Tue, 28 Jun 2022, 23:22 Joost van der Sluis via lazarus, <

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20220629/7677d040/attachment.htm>

Hi Joost,

i think i have a problem with this. When starting to debug with FpDebug on Windows 10 64bit i get the following error: TApplication.HandleException: EListError
Duplicate ID: 0000000000000000
Stack trace:
$00000001001EA1CF Error, line 383 of maps.pp
$00000001001E9DF8 InternalAdd, line 406 of maps.pp $00000001001EB362 Add, line 763 of maps.pp
$0000000100D686E6 AddFDE, line 508 of fpdbgdwarfcfi.pas $0000000100D36112 LoadCallFrameInstructions, line 4022 of fpdbgdwarfdataclasses.pas $0000000100D0CDA0 LoadInfo, line 1754 of fpdbgclasses.pp $0000000100D0F172 LoadInfo, line 2392 of fpdbgclasses.pp $0000000100D70706 SendEvents, line 1808 of fpdbgcontroller.pas $0000000100FB66C8 DebugLoopFinished, line 3850 of fpdebugdebugger.pas $0000000100FA6B81 LoopFinished_DecRef, line 677 of fpdebugdebugger.pas $000000010005FD3E ProcessAsyncCallQueue, line 1082 of include/application.inc $000000010005DD52 Idle, line 441 of include/application.inc $0000000100060759 HandleMessage, line 1281 of include/application.inc $0000000100060E77 RunLoop, line 1417 of include/application.inc $00000001000CCAD5 AppRun, line 54 of include/interfacebase.inc $0000000100060E27 Run, line 1405 of include/application.inc $0000000100003784 $main, line 154 of lazarus.pp

Pascal

Hi Joost,

i did this to temporary solve it for me:

components/fpdebug/fpdbgdwarfdataclasses.pas | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/components/fpdebug/fpdbgdwarfdataclasses.pas b/components/fpdebug/fpdbgdwarfdataclasses.pas
index 67c715b762..e62726658b 100644
--- a/components/fpdebug/fpdbgdwarfdataclasses.pas
+++ b/components/fpdebug/fpdbgdwarfdataclasses.pas
@@ -4019,7 +4019,8 @@ begin
           if FDE32^.Length > 0 then
             begin
             FDE := LoadFDE(CFI, FDE32^.CIEPointer, @FDE32^.InitialLocation, @FDE32^.CIEPointer+FDE32^.Length- at FDE32^.InitialLocation);
-            CFI.AddFDE(FDE);
+            if FDE.InitialLocation  0 then
+              CFI.AddFDE(FDE);
             end
           else
             // This should never happen, but it did and it leads to a range-check

Pascal

Op 29-06-2022 om 09:59 schreef Pascal Riekenberg via lazarus:

i did this to temporary solve it for me: components/fpdebug/fpdbgdwarfdataclasses.pas | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

I've committed something similar. I suppose you are using fpc 3.2.3?

Regards,

Joost.

I use fpc trunk (3.3.1)

Pascal

Op 29-06-2022 om 10:31 schreef Pascal Riekenberg via lazarus:

I use fpc trunk (3.3.1)

Seems there is a problem in the internal linker on Windows. It does not properly relocate the CFI information.

You can compile with '-Xe' to use the external linker. That also fixes this problem and this way the CFI information is more reliable. Until the internal linker is fixed.

Regards,

Joost.

Ok, thanks for the hint!

Pascal