Lazarus
Using the Lazarus IDE => Editor => Topic started by: Artlav on March 31, 2017, 08:14:20 pm
-
As reported in a bug here: http://bugs.freepascal.org/view.php?id=31577
In short, if a file is in a directory which is itself a symlink, then different tab (with the physical path of the file) would be open for the debugger to step into than the one the editor normally opens (and does stuff like setting breakpoints).
This is a critical issue for me, since i use symlinks extensively, and it worked just fine on Windows or in Delphi 7 via WINE.
While Git had a good reasoning behind it's hate of symlinks, this Lazarus one is just a plain bug.
So, the question is - where in the Lazarus code should i look to find the code responsible for opening tabs or finding paths to files?
I tried digging into it and searching, but it really should have a "Abandon all hope, ye who enter here" written at the entrance...
I thought it might be related to gdb telling the IDE what to do, but gdb parses the path properly.
I thought it might be something in function TFileOpener.OpenEditorFile, but it opens the files-as-symlinks properly.
Beyond that i don't really know where to look...
-
from very distant memory.
The IDE debugger asks gdb to provide the path/filename. (And that is based on what fpc put into the debug info, and what gdb makes of it)
You can then trace it from the stackwindow (debugger/callstackdlg).
procedure TCallStackDlg.JumpToSource;
The stack window code is probably easier to follow than the code in gdbmidebugger. (packages lazdebbugergdbmi)
TGDBMIDebuggerCommandExecute.ProcessStopped and then *probably* ProcessFrame ... FOnCurrent....
The callstack takes you to
TDebuggerDlg.JumpToUnitSource
and eventually to
MainIDEInterface.DoJumpToSourcePosition
At some stage the package manager and/or codetools get involved....
----------------
Anyway you can start the IDE in the debugger, and debug it while it debugs some other project.
Then you can set breakpoints in the above locations and see where it takes you.
-
from very distant memory.
Ok, good, thanks for some pointers.
Intercepted it at TDebugManager.DebuggerCurrentLine in debugmanager, tracking.
It's getting fed to it from above, from gdbmidebugger... This is going to be F.U.N.
On a side note, it's so bizarre to be debugging an IDE that does the debugging of a project. %)
-
So, in TGDBMIDebuggerCommandBreakInsert.ExecBreakInsert it passes the correct name to the GDB:
-break-insert "\"/domain/prg/prg/aedis/rtl/rtl_test/alib/maths_big.pas\":535"
And GDB replies:
^done,bkpt={number="144",type="breakpoint",disp="keep",enabled="y",addr="0x000000000043ca57",
func="MATHS_BIG_TEST",file="alib/maths_big.pas",fullname="/domain/prg/prg/algorlib/maths_big.pas",
line="535",thread-groups=["i1"],times="0",original-location="/domain/prg/prg/aedis/rtl/rtl_test/alib/maths_big.pas:535"}
...damn.
Looks like it's a GDB-related issue, and there would either be a one-config-line fix, or fixing this would take a while and involve some system to corellate project file names and returned names... Murphy says it's the latter.
Anyone happen to have any ideas of how to change the GDB behavior on this, while i look around?
-
Ok, fixed it.
Basically, i let it look up the relative path in TDebugManager.GetFullFilename, since it is already equipped to parse such names.
Patch below.
Anyone see a reason why this could break anything?
I've ran it across many of my projects and encountered neither issues, nor the bug, but i'm nothing even remotely close to typical language/RAD user.
From 90af9b6fb854df5a53869bad4503f0d250018d95 Mon Sep 17 00:00:00 2001
From: Artem Litvinovich <theartlav@gmail.com>
Date: Sat, 1 Apr 2017 00:43:43 +0300
Subject: [PATCH] Fixed symlink tab issue
---
ide/debugmanager.pas | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ide/debugmanager.pas b/ide/debugmanager.pas
index 18d8a7d39a..8186457403 100644
--- a/ide/debugmanager.pas
+++ b/ide/debugmanager.pas
@@ -559,7 +559,8 @@ function TDebugManager.GetFullFilename(const AUnitinfo: TDebuggerUnitInfo;
procedure ResolveFromDbg;
begin
- Filename := AUnitinfo.DbgFullName;
+ //Filename := AUnitinfo.DbgFullName;
+ Filename := AUnitinfo.FileName;
Result := Filename <> '';
debugln(DBG_LOCATION_INFO, ['ResolveFromDbg Init Filename=', Filename]);
if Result then
--
2.12.1
-
I havent used the dotted name-space units that fpc now supports.
How are they saved?
Can (with dotted names) 2 units have the same filename?
Also need to test how/if this works with older gdb. On some windows versions, newer gdb are less stable.
But it could certainly be made an option (debugger properties).
Then it can be patched into the IDE, and anyone using symlinks can switch it on.