Question about the future, to debug with Lazarus lazarus / 12-Debugger ---------------------------------------------------------------------- devEric69 · 2019-12-30 08:57 Hello, I know that GDB is a very, very, very good debugger... but completely oriented towards C grammar, so it's difficult to be adapted with the grammar of Pascal souce code - even with the simple parts of the current grammar. And I know that, those who are interfacing GDB and FPC, are doing everything they can, ie a good job. I thank them for that. My question is for the future: is there currently, a really strategic debugger developpement that has factually a huger potential to be much more "grammar Pascal friendly" than the others developpements: would it be to continue the front-end adaptation from GDB for Pascal, or to continue the developpment of others (LazDebuggerFp, debuggerIntf + LazDebuggerGdmi) or something else (a code mix between several solutions) ? Briefly, if such a debugger, having strategically more potential than the others (even if it is lagging behind other solutions, at the moment), I'd like to know about it... to use it definitively . Best regards. ---------------------------------------------------------------------- ccrause · 2019-12-30 10:26 In my mind the future (in the context of this forum) lies with FpDebugger. For me there are three reasons: it targets FPC code specificallyit is written in Pascalactive maintainer (Martin Friebe)Obviously there are negatives to moving away from gdb, the main being the long list of supported targets of gdb.  Howevr, gdb doesn't seem to update FPC's Pascal enhancements into its Pascal language support (and this is understandable) so as FPC develops, more glue code needs to be written to interpret gdb's results. Although FpDebugger is not yet properly designed for multi-target support I've started adding AVR support and would like to change the design so that it is easier to add new targets. ---------------------------------------------------------------------- devEric69 · 2019-12-30 11:22 Quote FpDebugger. For me there are three reasons: [snip]     active maintainer (Martin Friebe) This is what I noticed on GitHub: several debuggers have been written, but they also seem to have been "forgotten", even if they contain good ideas. Quote[snip] as FPC develops, more glue code needs to be written to interpret gdb's results Indeed, on the GDB site, compatibility with Pascal grammar clearly doesn't seem to be their priority. And I also much prefer to report problems (or successes) to a software that is always maintained. Thank you for your arguments. ---------------------------------------------------------------------- Martin_fr · 2019-12-30 12:41 Quote from: devEric69 on December 30, 2019, 12:22:25 pmQuote FpDebugger. For me there are three reasons: [snip]     active maintainer (Martin Friebe) This is what I noticed on GitHub: several debuggers have been written, but they also seem to have been "forgotten", even if they contain good ideas. Not sure where you are looking, but fpdebug is all but forgotten. It had plenty of work done during the past year. And all that work is in SVN and will be in Lazarus 2.2. Installing LazDebuggerFp (which is part of the Lazarus installation) will allow you to use it on Windows and Linux. (I am using it as my main Debugger on Windows). On Mac, support is still lacking, and once done will need code- signing. But on Mac you can install LazDebuggerFPlldb (the one with "FP").  Based on lldb, it uses fpdebug to evaluate expressions, and lldb to read memory. It hasn't got any new features yet. https://wiki.lazarus.freepascal.org/Debugger_Status ---------------------------------------------------------------------- devEric69 · 2019-12-30 13:20 Probably a silly question, but it's just to be sure: - @ccrause is talking about " FpDebugger ". - You, @Martin_fr, are talking about " fpdebug " (LazDebuggerFp package). ==> Are you both talking about the same debugger, i.e. FpDebugger = fpdebug ? ---------------------------------------------------------------------- Martin_fr · 2019-12-30 13:42 Yes, both the same. (Though IIRC there was an external project that was also named fpdebug / maybe a fork, maybe stand alone / but afaik not active now) FpDebug is the name of the core package in Lazarus for pascal based debugger support. That package contains functions and classes to read debug info, interact with the OS debug API, and anything else one might need to write a debugger. If you look at the debugger status wiki, you can see it is use by several debuggers. LazDebuggerFp is the package that implements a working debugger based on FpDebug for the IDE. And the unit inside the package is called FpDebugDebugger... But there are several other packages that use FpDebug, combined with gdb or lldb. They were created when FpDebug was not stable enough on its own. LazDebuggerFpLldb is the current recommended debugger for Mac. Other than the above the names "FpDebug" / "FpDebugger" are used freely for anything related to /based on FpDebug. There is no clear definition when to use which name. When you install LazDebuggerFp, it show as "FpDebug (internal DWARF- debugger (beta)). So naming is really all over the place. ---------------------------------------------------------------------- Martin_fr · 2019-12-30 13:59 There is also a difference between the debugger frontend and backend (from the IDE points of view). All the debuggers mentioned in this thread are backends.  As for LazDebuggerGDBMI the backend from the point of the IDE is the code wrapping around gdb.exe. gdb.exe itself is the backend of the backend.... The backend determines how an expression is parsed. I.e. knowing what operators pascal has. Currently the backend also formats the data for display (though that should move (at least partly) to the frontend). FpDebug currently has very verbose formatting. That is subject to change / feedback welcome. The frontend provides all the debug windows. I.e. how you add a watch, and specify the properties of a watch. The frontend would also be the place where multi line formatting for structures would need to be supported. What data is available, is actually determined by FPC. FPC writes debug info to the exe. Only data available in this debug info can be shown. FpDebug does a tiny bit more, trying to detect dyn-array and ansistring, and applying some knowledge about FPC internals. (Which means future fpc can change, and break this). FPC does not write any information about properties (except "read FField"). So they do not exist in the debugger. The debugger does not parse the sources, as they could have changed after compilation. And even then, the sources do not contain the address at which a symbol can be found in the compiled exe. ---------------------------------------------------------------------- Martin_fr · 2019-12-30 14:21 A list of implemented operators in FpDebug: https://wiki.lazarus.freep ascal.org/FpDebug#Watches_.2F_Locals_.2F_Inspect More can be added fairly simple. About auto-deref (Delphi mode), which allows to skip the ^ operator. This currently requires compilation of the IDE with a define -dFpDebugAutoDerefMember ---------------------------------------------------------------------- ccrause · 2019-12-30 14:23 Quote from: Martin_fr on December 30, 2019, 02:42:54 pm(Though IIRC there was an external project that was also named fpdebug / maybe a fork, maybe stand alone / but afaik not active now) I know of Graeme's fpdebug version, starting from Duby.  From the histories of this and the Lazarus FpDebug version it seems as if the two projects started almost in parallel. ---------------------------------------------------------------------- devEric69 · 2019-12-30 15:04 Thank you very much for this clarification on the different layers constituting the structure of this "FpDebug" or "FpDebugger" solution. QuoteThere is no clear definition when to use which name. Maybe some "GNU-marketing" in the Wiki could decide how to call it uniquely ( I suggest "solutions based on the unique ^[F|f]pDebug*$" ), to emphasize its uniqueness, so to make it shine brighter . Quote[snip]Which means future fpc can change, and break this[snip] I don't have debugger writing skills. But, isn't it possible to serialize some FPC and FpDebug* sources, in order to add unit tests to avoid debugger regressions when changing the FPC (I know: with "ifs" and "just do this or that...", I can write the best debugger of the world in 1 day  )? QuoteA list of implemented operators in FpDebug: https://wiki.lazarus. freepascal.org/FpDebug#Watches_.2F_Locals_.2F_Inspect More can be added fairly simple. That seems very good: because knowing the pointed or not structure \ type \ method \..., it seems to be easier to keep track of much more information than with the mixed solution with GDB (I've tried C-like typecasts, or dereferences with * to trace addresses with GDB, but it doesn't accept them; the Pascal layer that surrounds it, I guess; while the use of tokens like @, ^, ... are the first things I'm thinking). Anyway, being able to introspect the pointers more "in depth", necessarily makes me more serene, about the probabilities of being able to understand any bug. ---------------------------------------------------------------------- Martin_fr · 2019-12-30 15:23 Quote from: devEric69 on December 30, 2019, 04:04:05 pmQuote[snip]Which means future fpc can change, and break this[snip]I don't have debugger writing skills. But, isn't it possible to serialize some FPC and FpDebug* sources, in order to add unit tests to avoid debugger regressions when changing the FPC (I know: with "ifs" and "just do this or that...", I can write the best debugger of the world in 1 day  )? There are testcases. So it can be detected, but it then needs an update. An old version of FpDebug may not work 100% with a new version of FPC. This is only a tiny part that is affected. There is an official standard called DWARF. It defines how a compiler tells a debugger about all the functions and variables. But DWARF does not define the difference between "Ansistring" and "array of char". So FpDebug looks for hints outside the standard. If those hints change, then a string may be shown as array of char, or vice versa. In some versions, (dwarf/fpc versions) AnsiString are encoded as PChar. (which is way "mystring[1]" is sometimes returning 2 results, because pchar is 0-based and string is 1-based). Similar stuff exists for shortstring, which really is a record. QuoteQuoteA list of implemented operators in FpDebug: https://wiki.laz arus.freepascal.org/FpDebug#Watches_.2F_Locals_.2F_Inspect More can be added fairly simple. That seems very good: because knowing the pointed or not structure \ type \ method \..., it seems to be easier to keep track of much more information than with the mixed solution with GDB (I've tried C-like typecasts, or dereferences with * to trace addresses with GDB, but it doesn't accept them; the Pascal layer that surrounds it, I guess; while the use of tokens like @, ^, ... are the first things I'm thinking). Anyway, being able to introspect the pointers more "in depth", necessarily makes me more serene, about the probabilities of being able to understand any bug. gdb gets confused with pointers to structures in arrays, or nested pointers. In general (as far as I tested) fpdebug can deal with them (that is fpdebug in svn trunk) You can quickly test this by double clicking fields in the "debug inspector". (IDE debug window) IIRC for pointer arithmetic, fpdebug uses typed pointers ("@" returns a typed pointer / increase according to the size of the data pointed to.) Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i (@struct + 1)^points to the next item, rather than one byte into the current item. ---------------------------------------------------------------------- devEric69 · 2019-12-30 15:42 Quotefpdebug uses typed pointers ("@" returns a typed pointer / increase according to the size of the data pointed to.) Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i     (@struct + 1)^points to the next item, rather than one byte into the current item. Okay, I anderstand. And depending on what the next item is...: - ...we get a real char, or maybe the last and final #0, if the struct is a PChar. - ...we get a typed pointer, if it's an item Object of a TList ==> so, we look for the type of the pointer of this next TList's pointer which points on the stored object let's say TFoo - so the typed pointer is ^TFoo - and we can find something like ^TFoo((@struct + 1)^).FsMyString, for example. - etc. ---------------------------------------------------------------------- Martin_fr · 2019-12-30 15:46 Quote from: devEric69 on December 30, 2019, 04:42:53 pm let's say it's ^TFoo - and we can find something like ^TFoo((@struct + 1)^).FsMyString, for example. Should work. If not, should be fixable (without waiting for gdb fixes). Also understands @struct[n] ---------------------------------------------------------------------- Martin_fr · 2019-12-30 15:52 Anyway, if you can install Lazarus trunk, then you should test it. Testers is what is needed, to get it better. What OS are you on? On Mac => use LazDebuggerFpLldb. All watches parsing is done via fpdebug. On Win/Linux => use LazDebuggerFp ---------------------------------------------------------------------- devEric69 · 2019-12-30 15:53 QuoteAlso understands @struct[n]I'll work on it (edit: I'm on Linux, Ubuntu edition with GDB; but I've already installed it and used it very, very briefly on a Win7 32-bit netbook: I didn't encounter any problem with it; I'll install and test it on my Linux 64 bits). Thank you, sir . ---------------------------------------------------------------------- mm7 · 2020-03-02 18:31 Quote from: Martin_fr on December 30, 2019, 02:59:19 pmThere is also a difference between the debugger frontend and backend (from the IDE points of view). All the debuggers mentioned in this thread are backends.  As for LazDebuggerGDBMI the backend from the point of the IDE is the code wrapping around gdb.exe. gdb.exe itself is the backend of the backend.... ... Hi Martin, after your advise I've just started using Valgrind. It is very powerful tool. And it can interface with GDB debugger. So, when Valgrind captures an issue, like a wrong memory access, it can stop there, and you can investigate it further in GDB. I tried to attach to this VGDB-GDB from Lazarus, but it was unsuccessful. You know I wrote about it in another thread. My question. Is it possible to add something to LazDebuggerGDBMI, or, if syntax and commads of GDB with external VGDB are too different, to fork it to something like LazDebuggerValgrindGDB ? ---------------------------------------------------------------------- Martin_fr · 2020-03-02 18:52 Quote from: mm7 on March 02, 2020, 07:31:23 pmHi Martin, after your advise I've just started using Valgrind. It is very powerful tool. And it can interface with GDB debugger. So, when Valgrind captures an issue, like a wrong memory access, it can stop there, and you can investigate it further in GDB. I tried to attach to this VGDB-GDB from Lazarus, but it was unsuccessful. You know I wrote about it in another thread. My question. Is it possible to add something to LazDebuggerGDBMI, or, if syntax and commads of GDB with external VGDB are too different, to fork it to something like LazDebuggerValgrindGDB ? It should be.... The IDE uses the "MI" interface of gdb: -i mi If that is not supported, I expect it to be a lot of work. Otherwise... Does vgdb start valgrind? Can you do vgdb -i mi myexe and then "r" for run, and it will start valgrind? If so, when and where do you pass the arguments to valgrind? ---------------------------------------------------------------------- mm7 · 2020-03-02 20:47 VGDB does not start Valgrind. Opposite. Valgrind starts vgdb process and you start GDB and in GDB you type command `target remote | vgdb'. So GDB connects to vgdb. After that, supposedly, one could work in GDB a normal way. However there are some differences. Like you cannot do `run' command, which I suspect Lazarus tries to issue and it fails to continue. If it would be something like a configurable script of commands that replaces normal Lazarus GDB init script, that may be could solve the initialization issue. I am not sure if Lazarus can connect to VGDB directly. wait a second I see VGDB can listen on a TCP port. There is a chance to attach Lazarus to it with Remote GDB (gdbserver) ---------------------------------------------------------------------- mm7 · 2020-03-03 05:55 Test is positive! 1. In Lazarus Options set Debugger Type "GNU remote debugger (gdbserver)" Debugger Remote Host = localhost Debugger Remote Port = 33333 2. Optionally in Project Options / Debugger set Generate code for valgrind = yes. 3. Build the program 4. In shell A run: valgrind --tool=memcheck --leak-check=yes --vgdb- error=0 ./myprogram 5. In shell B run: vgdb --port=33333 6. In Lazarus run the program (with debugger) (F9) Lazarus via vgdb communicates with program in valgrind. It understands breakpoints, shows var values like regular GDB. Also it stops on lines where Valgrind throws exception, where normally no exception happens (line 4 below). Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i   mo:=TMyObj.Create;  mo.Field:=12345;  mo.Free;  if mo.Field = 0  then exit;  yes, starting debugger in 2 addition shell windows is not very convenient. But I'll try to add a start script via Run Parameters. ---------------------------------------------------------------------- Martin_fr · 2020-03-03 08:26 Please document it on the wiki ---------------------------------------------------------------------- mm7 · 2020-03-03 15:00 I have difficulties with finding a proper space for the document. Could you please advise? ---------------------------------------------------------------------- Martin_fr · 2020-03-03 15:19 Debugging pages are all listed under https://wiki.lazarus.freepascal.org/Category:Debugging You may start a new page dedicated to valgrind. If you do, make sure to add  [[category:Debugging]] And link it from relevant pages such as the "See also" of * https://wiki.lazarus.freepascal.org/Debugger_Setup * https://wiki.lazarus.freepascal.org/Debugger * https://wiki.lazarus.freepascal.org/IDE_Window:_Debugger_Options * https://wiki.lazarus.freepascal.org/IDE_Window:_DebuggerClassOptions Frame and maybe other pages that refer valgrind already (wiki search) ---------------------------------------------------------------------- mm7 · 2020-03-04 13:19 I've created article in sandbox https://wiki.freepascal.org/Debugging_with_Valgrind But I do not see it in the section https://wiki.freepascal.org/Category:Debugging Yes I've added in the end [[Category:Debugging]] [[Category:Lazarus]] ---------------------------------------------------------------------- Martin_fr · 2020-03-04 13:46 There is a bug in the wiki, it will take some time for the category page to update. ---------------------------------------------------------------------- trev · 2020-03-05 00:09 Quote from: mm7 on March 04, 2020, 02:19:49 pmYes I've added in the end [[Category:Debugging]] [[Category:Lazarus]] I deleted them again. They are included in the page template (https://wiki.lazarus.freepascal.org/Template:Debugging_with_Valgrind) for the page and so do not need to be repeated in the page. ---------------------------------------------------------------------- avra · 2020-03-05 07:53 Quote from: mm7 on March 04, 2020, 02:19:49 pmI've created article in sandbox https://wiki.freepascal.org/Debugging_with_ValgrindThank you! ---------------------------------------------------------------------- dparnaby · 2020-05-01 22:44 I used to use GNU debugger on a fairly large project and have changed to FPDebug Internal Dwarf - debugger (Beta) with the project set to Dwarf 3 (beta) -gw3 The operating system is Windows 7 It appears to be faster and has worked up to expectations. In upgrading from lazarus 2.0.6 to 2.0.8 the debugger information was not recognized with  fpDebugger or GNU set. I created new projects and copied over the lpr content to this new project and it worked. No idea what the problem was but it is up and running in Lazarus 2.0.8 ---------------------------------------------------------------------- avra · 2020-05-01 23:19 Quote from: dparnaby on May 02, 2020, 12:44:08 amIn upgrading from lazarus 2.0.6 to 2.0.8 the debugger information was not recognized with  fpDebugger or GNU set.Have you tried a clean rebuild of the old project? ---------------------------------------------------------------------- Martin_fr · 2020-05-02 00:13 Quote from: dparnaby on May 02, 2020, 12:44:08 amIn upgrading from lazarus 2.0.6 to 2.0.8 the debugger information was not recognized with  fpDebugger or GNU set. What message did you get? ---------------------------------------------------------------------- dparnaby · 2020-05-02 18:41 Quote from: avra on May 02, 2020, 01:19:15 amQuote from: dparnaby on May 02, 2020, 12:44:08 amIn upgrading from lazarus 2.0.6 to 2.0.8 the debugger information was not recognized with  fpDebugger or GNU set.Have you tried a clean rebuild of the old project? Yes - I deleted all ppu's and o's and rebuilt packages and program. The error was something like "There is no debug information available" In future before making a post I will ensure I record exact information . To reconstruct the problem now will take some time. Anyway there are no gatchas now and I have no problems. Maybe it was something in the lpi or lps Lazarus has fulfilled my every expectation after switching from Delphi thank you david