How to register debugger from package? lazarus / 12-Debugger ---------------------------------------------------------------------- v.denis · 2013-10-05 09:09 I'd like to register some simple (skeleton) debugger from package. The problem I encounter is that using BaseDebugManager unit to register debugger need ide package which is runtime only. And making my package runtime will not install it into IDE? I want to use package to avoid modifying Lazarus sources directly. Adding my runtime package into dependencies of Lazarus don't register debugger also. Am I missing something here? PS the project is https://code.google.com/p/vdbg/ ---------------------------------------------------------------------- v.denis · 2013-10-05 09:42 That's the main code, so I expect message box if it succeed. Code: [Select]unit wdbgMain; {$mode objfpc}{$H+} interface uses   Classes,   Dialogs,   SysUtils,   BaseDebugManager,   Debugger; procedure Register; implementation type   { TDebuggerSkeleton }   TDebuggerSkeleton = class(TDebugger)   public     // Override Caption and return our debugger name.     class function Caption: String; override;   end; procedure Register; begin   ShowMessage('Register TDebuggerSkeleton invoked');   RegisterDebugger(TDebuggerSkeleton); end; { TMyDbg } class function TDebuggerSkeleton.Caption: String; begin   Result:='Skeleton Debugger'; end; end. And what if I want a separate folder for this (inside Lazarus folder). What paths I should change to make Lazarus recompile successfully? Should I modify those makefiles hell? ---------------------------------------------------------------------- Martin_fr · 2013-10-05 09:47 This is a known problem. The debugger must at some point be moved into package(s). Until then you have to copy your unit to the IDE, and use it from within the IDE (all other debugger are used in ide/debuggmanager.pas ---------------------------------------------------------------------- Martin_fr · 2013-10-05 10:01 The makefiles are auto generated. PROBABLY you can add the path to the ide/lazarus.lpi. If that does not work, then I do not know. (You may get more responses on this topic (adding path to IDE) on the mail list. Another suggestion: Only one of your units contains the debugger class that is forced (by inheritance) into the ide. So keep the rest in the package, and move that one file into the IDE. Then add the package (it does not register anything, so the ide will say there is no need, but it still lets you add it). ---------------------------------------------------------------------- v.denis · 2013-10-05 10:06 Thanks. Adding the path to the ide/lazarus.lpi (it does automatically when unit added through project manager) doesn't work. When rebuilding Lazarus from Tools\Build Lazarus.. it writes cannot find unit. Will try your suggestion. ---------------------------------------------------------------------- Martin_fr · 2013-10-05 10:21 What are your plans? fpdebug, duby, something new? ---------------------------------------------------------------------- v.denis · 2013-10-05 10:26 Simple Windows-only debugger. Some parts of dwarf parsing I can see implemented in fpdebug. ---------------------------------------------------------------------- Martin_fr · 2013-10-06 20:12 Quote from: v.denis on October 05, 2013, 12:26:16 pmSimple Windows- only debugger. Some parts of dwarf parsing I can see implemented in fpdebug. Make sure to use trunk. A am working on a similar project at the moment (very early alpha / no time frame or anything yet). If your motivation was to add features, you may still continue your approach, as I will probably first replicate existing functionality. Also my plan is (at this point) a hybrid of gdb and fpdbg/dubi: That is some functionality will be done by fp/dupi, the remainder still goes to gdb. ---------------------------------------------------------------------- v.denis · 2013-10-07 06:20 Currently I have no huge plans. At least making skeleton debugger which can start/stop process and stop on breakpoints would be good. If I succeed that then I can advance adding more things. ---------------------------------------------------------------------- jwdietrich · 2013-10-07 07:14 Quote from: v.denis on October 07, 2013, 08:20:16 amCurrently I have no huge plans. At least making skeleton debugger which can start/stop process and stop on breakpoints would be good. If I succeed that then I can advance adding more things. Even a tiny, simple debugger would be a large improvment, especially if it were cross-platform compatible. This is the more important since GDB is no longer bundled with Xcode 5 for Mac OS 10.9 Mavericks. ---------------------------------------------------------------------- v.denis · 2013-10-07 10:27 Now learning FpGdbmiDebugger and GDBMIDebugger sources. Just wondering when there is exception in debuggee (or debuggee was terminated by user, not IDE command), how it must be passed to IDE. ---------------------------------------------------------------------- Martin_fr · 2013-10-07 10:29 look for ProcessStopped, that is pause, exception, breakpoint, terminated .... ---------------------------------------------------------------------- Graeme · 2013-10-08 12:13 Quote from: v.denis on October 05, 2013, 12:26:16 pmSimple Windows- only debugger. Some parts of dwarf parsing I can see implemented in fpdebug. There is also fpdebug - my fork of the 'dubi' debugger. Looking at my github repository now, I still have lots of offline change I must push to github. I think this project is a good starting point though. My primary focus is on using DWARF as the debugging format.  https://github.com/graemeg/fpdebug ---------------------------------------------------------------------- Martin_fr · 2013-10-08 12:32 This is a fork of dubi? So despite the name not directly related to fpdebug (not any more than dubi, which afaik took some small parts from fpdebug)? Does it have any *completed* code to actually read variables or types? Mind, that the original fpdebug was very memory hungry, and as a result slow. I have not tested duby, but I found similar structures, and expect similar results. I improved those things in the fpdebug that is in Lazarus. Just some figures (intel dual core pentium 4 or 5 years old) Loading the dwarf info from Lazarus.exe (has about 15 million dwarf information entries): * original, fddebug compiled with -gh: out of mem (my system is 32 bit win vista with 3GB) * original, fddebug without -gh : 1 minute 650MB of mem * now between 4 and 7 sec (depends on disk cache, if all files are in mem cache, then 4 sec / fully optimized 2.5 seconds) 250 MB ---------------------------------------------------------------------- jwdietrich · 2013-10-08 12:37 In my over 20-years experience with Pascal programming the best debugger ever was LightsBug, a debugger that was bundled with THINK Pascal for classical Mac OS. As early as 1986 it featured a rich feature-set like display of structured datatypes, call hierarchy and a memory dump, all in a single small window. Perhaps its most useful feature was the possibility to traverse through complex pointer structures with simple double-clicking, since every pointer was treated like a hyperlink. None of the newer debuggers did reach the quality of LightsBug. Perhaps it is possible to implement at least a part of these features in a future debugger for Lazarus / Free Pascal. See http://basalgangster.macgui.com/RetroMacComputing/The_Long_View/En tries/2010/3/20_MacPascal_and_Think_Technologies.html and http://www.firebaugh.com/FDA/Courses/CS.320/Week.3/Lect5.html for more info and reference. ---------------------------------------------------------------------- Martin_fr · 2013-10-08 12:45 Being able to follow pointers, expand structures is something, I have often thought off myself, and is on my todo. It will of course need a custom control to display the data. The current grid is to limited.  Until now however all time went into getting usable results from gdb at all. (Still not 100% there). It will still be a while before I will look into this... ---------------------------------------------------------------------- marcov · 2013-10-08 12:51 Quote from: jwdietrich on October 08, 2013, 02:37:38 pmIn my over 20-years experience with Pascal programming the best debugger ever was LightsBug, a debugger that was bundled with THINK Pascal for classical Mac OS. As early as 1986 it featured a rich feature-set like display of structured datatypes, call hierarchy and a memory dump, all in a single small window. Perhaps its most useful feature was the possibility to traverse through complex pointer structures with simple double-clicking, since every pointer was treated like a hyperlink. None of the newer debuggers did reach the quality of LightsBug. Afaik 1.0.x supported this in the textmode IDE, (the functionality was called debug browser support, afaik the compiler part was compiler/Browcol.pas), and while the visualization wasn't perfect, it worked. I know it from topspeed, walking all structures in memory., ---------------------------------------------------------------------- v.denis · 2013-10-08 13:36 Well, Delphi debugger is quite powerful I suppose. It uses VirtualTreeView as far as I know. ---------------------------------------------------------------------- v.denis · 2013-10-08 13:37 I have created project https://code.google.com/p/vdbg/ a very basic Debug APIs are implemented now (still no exception support) ---------------------------------------------------------------------- jwdietrich · 2013-10-08 15:07 Quote from: v.denis on October 08, 2013, 03:37:07 pmI have created project https://code.google.com/p/vdbg/ a very basic Debug APIs are implemented now (still no exception support) Great! Are there insurmountable technical reasons why it is Windows- only? ---------------------------------------------------------------------- Graeme · 2013-10-08 16:53 Quote from: Martin_fr on October 08, 2013, 02:32:33 pmThis is a fork of dubi? So despite the name not directly related to fpdebug (not any more than dubi, which afaik took some small parts from fpdebug)? Sorry, that should have been "duby", not "dubi".  I was under the impression that the debugger included with Lazarus is called "fpd" - like GDB. I named the duby-fork  (fpdebug) a more like other FPC tools I work on. eg: fptest, etc. Anyway, it's just a name. QuoteDoes it have any *completed* code to actually read variables or types? I have made some changes and improvements over duby (64-bit, more DWARF support etc )... I stopped following duby development a long time ago - when it was dormant. I don't know if development has continued since then. To be honest, I haven't worked on my version of fpdebug in a long time either - paying work just keeps me too busy. :-( As for "fpd" (the one included with Lazarus). I thought that was a Windows only debugger, and I think Win64 specific too? Has that changed? Regarding performance and resource usage. I haven't looked at that at all. Just getting the debugger to actually debug was a bigger concern. ---------------------------------------------------------------------- Martin_fr · 2013-10-08 17:03 fpd(ebug) [the app was fpd, the folder fpdebug] was windows only. But after talking to Dmitri (duby), I imported the linux elf reader, and soon will get the mac reader too. If yours has support for even more systems, then at some point in time, with your permission, and if gpl, I may look through it, and copy parts that would be helpful. ---------------------------------------------------------------------- v.denis · 2013-10-08 17:55 Quote from: jwdietrich on October 08, 2013, 05:07:47 pmAre there insurmountable technical reasons why it is Windows-only? I don't think it is something insurmountable. For me it's the matter of resources available and motivation. I'm actually just learning Lazarus internals now. Thanks to Martin_fr and other guys for answering my boring questions Making this project I also want to see how fast debugger will be. Now process starts quite fast after linking is done (no antivirus). But there is no loading and parsing of debug info, which I guess is main time consumer. ---------------------------------------------------------------------- Martin_fr · 2013-10-08 18:14 a big time consumer is the environment. (See "Run Param" "Environment") Each of that values must be send to gdb (despite some gdb ignore it due to a gdb bug). That is a lot of GDB commands issued. Also, the IDE performs some tests at startup, to collect some info, it will need later. See "debugger output" in View > debug windows. OR Install LazIdeLogger package, then go to tools menu, and choose logging. - Enter a logfile (or compile IDE with console ( -WC ) - Enable DBG_CMD_ECHO to see gdb communications, There you can also watch the debugger state. -------------- IMHO startup time is not the big issue (it is for beginners, who work an small projects, needing many runs to find all the issues. Working on a big project, startup time becomes less important. After all it will take much longer to step through the project, and reach the location you are interested in. E.g an error in a function called from a loop: You need to reach the a breakpoint in the loop 5 times, only then, you can break in the function that you need to debug (because only then the error will show) Much more annoying to me, is the time it takes to evaluate watches. It does not matter with one or 2. But have a list of 20 watches. Including array-slices, and record/objects. ---------------------------------------------------------------------- jwdietrich · 2013-10-08 18:22 Quote from: v.denis on October 08, 2013, 07:55:19 pmI'm actually just learning Lazarus internals now. Thanks to Martin_fr and other guys for answering my boring questions Your questions are eveything but boring- ---------------------------------------------------------------------- v.denis · 2013-10-08 19:00 Quote from: Martin_fr on October 08, 2013, 08:14:33 pmE.g an error in a function called from a loop: You need to reach the a breakpoint in the loop 5 times, only then, you can break in the function that you need to debug (because only then the error will show) I agree, for such cases I use following pattern to trigger breakpoint Code: [Select]if (some_condition_right_before_failure) then asm   int 3 end; Quote from: Martin_fr on October 08, 2013, 08:14:33 pmMuch more annoying to me, is the time it takes to evaluate watches. It does not matter with one or 2. But have a list of 20 watches. Including array-slices, and record/objects. Indeed evaluating is used very often.  It's a pure hell now. btw gdb on Linux or Mac (in Lazarus) is it fast enough? ---------------------------------------------------------------------- Martin_fr · 2013-10-08 19:06 gdb is of similar speed on most platforms. You know that you can set hitcount and condition on breakpoints? - Make a breakpoint stop after n hits. - Make a breakpoint stop only on condition "var=value" - Have a disabled breakpoint automatically enabled, after another breakpoint was hit and much more ---------------------------------------------------------------------- v.denis · 2013-10-08 19:15 I guess I saw it in breakpoint properties. ---------------------------------------------------------------------- v.denis · 2014-04-06 13:44 I see there are lot of changes in debugger system is going now (svn) since my last activity here. Looks like debuggers now can be registered from package. And lazdebuggerfp package now is alpha (\components\lazdebuggers\lazdebuggerfp\) Just wondering what is implemented in lazdebuggerfp. FpDbgWinClasses seems to have quite a lot. I installed lazdebuggerfp package, selected "fpDebug internal Dwarf- debugger" in options. When trying to F9 it kind of freeze. In Run state, cant stop it or pause. As I see current debug interface is quite good, so I probably will deprecate my vdbg project and maybe can create some patches for fpDebug. ---------------------------------------------------------------------- Martin_fr · 2014-04-06 14:38 There are now 2 approaches LazDebbuggerFP / LazDebuggerFpGDBMI ----------- LazDebbuggerFP: maintained by Joost Afaik not yet ready, except for Mac, (maybe linux). He said Windows was not ready. - Does not yet have watches, that will be added in the near future. - Does not have stacktrace (and can not watch except for top stackframe). That will be longer to fix It does not use gdb, so it is limited to what fpdebug can LazDebuggerFpGDBMI hybrid between gdb and fpdebug. May have bugs, but should do all, that the gdb debugger can do. Does (some) Watches without gdb. -------------- No: neither of them can do properties. And it will be a long time before they can.