fpdebug stand-alone ? lazarus / 62-General ---------------------------------------------------------------------- Fred vS · 2021-11-19 16:58 Hello. About https://wiki.freepascal.org/FpDebug. Is it possible to compile fpdebug as stand-alone executable and use it like gdb, on console ? If yes, how to do, I see part of code in fpc and Lazarus too. Thanks. ---------------------------------------------------------------------- Martin_fr · 2021-11-19 17:14 There is a sample project in the fpdebug folder. But it is not maintained, and currently does not compile. It may also not be complete. But in general, FpDebug can be used outside the IDE (like Joost's DAB version). So it is possible, if someone writes and maintains the code. If you are interested I can answer questions. LazdebuggerFp would be the first point of study. So you only need the part that interacts with FpDebug. Threading is only needed, if you wont the console-dbg-app responsive while running. E.g. if you want to be able to "interrupt" the running target app. Because FpDebug does only return from "run" when it hits a breakpoint, or otherwise stops. Note that on some OS (linux) all kernel calls must be in the same thread. So other threads cannot call FpDebug functions that inspect the target. (This is part of what makes LazDebuggerFp so complex) FpDebug will probably still undergo some changes to its API. ---------------------------------------------------------------------- Fred vS · 2021-11-19 17:33 Quote from: Martin_fr on November 19, 2021, 06:14:02 pmThere is a sample project in the fpdebug folder. But it is not maintained, and currently does not compile. It may also not be complete. But in general, FpDebug can be used outside the IDE (like Joost's DAB version). So it is possible, if someone writes and maintains the code. If you are interested I can answer questions. LazdebuggerFp would be the first point of study. So you only need the part that interacts with FpDebug. Threading is only needed, if you wont the console-dbg-app responsive while running. E.g. if you want to be able to "interrupt" the running target app. Because FpDebug does only return from "run" when it hits a breakpoint, or otherwise stops. Note that on some OS (linux) all kernel calls must be in the same thread. So other threads cannot call FpDebug functions that inspect the target. (This is part of what makes LazDebuggerFp so complex) FpDebug will probably still undergo some changes to its API. OK, thanks Martin, I will jump into LazdebuggerFp (asap), write you later. Fre;D ---------------------------------------------------------------------- Fred vS · 2021-11-19 18:18 Quote from: Martin_fr on November 19, 2021, 06:14:02 pmThere is a sample project in the fpdebug folder. But it is not maintained, and currently does not compile. It may also not be complete. OK for compiling ( after very few modif ), but seems to have problem with Json while running. Hum, maybe too deep for me to jump into this... ---------------------------------------------------------------------- Martin_fr · 2021-11-19 18:24 The stand-alone console version is fpd/fpd.lpr I haven't checked what the fpdserver does / what client it needs. ---------------------------------------------------------------------- ccrause · 2021-11-19 18:41 Quote from: Martin_fr on November 19, 2021, 07:24:48 pmThe stand-alone console version is fpd/fpd.lpr Yes, fpd is more like a very basic gdb console application. It exposes only basic functionality, see the help listing for commands supported. ---------------------------------------------------------------------- Martin_fr · 2021-11-19 18:47 Yes, but you can add commands. E.g. Change the stack frame (or thread) for eval commands. You need to store the given thread/frame in the fpd app. Then get the correct context (and make sure the stackframe is prepared), and eval with that context. The same is for a hit count on breakpoints. At the moment, stepping after exceptions is partly done in LazDebuggerFp => that needs review, and maybe some may move into fpdebug. Also FpDebug needs more support for dll, and setting breakpoints for dll that are not yet loaded.... But those things still have to be done from scratch. ---------------------------------------------------------------------- Fred vS · 2021-11-19 19:05 Quote from: Martin_fr on November 19, 2021, 07:24:48 pmThe stand-alone console version is fpd/fpd.lpr Ha, OK, after some light modifs, it compiles and run. But while loading the binary to debug after the "run" command it crash. Imho, it will be great to have a console fpdebug version working. ---------------------------------------------------------------------- Martin_fr · 2021-11-19 19:08 like any threaded app on linux... uses cthreads That is fpc, not fpdebug. ---------------------------------------------------------------------- Fred vS · 2021-11-19 19:13 Quotelike any threaded app on linux... uses cthreads Ooops, of course, added and it works ( but you may also add some {$ifdef unix}cthreads,{$endif}, it does not hurt  ) OK, compiled with cthreads and it works. Nice. ---------------------------------------------------------------------- Martin_fr · 2021-11-19 19:13 Since it is threaded, ensure to test with -dFPDEBUG_THREAD_CHECK And of course -Sa and all the bells and whistles.... For logging, you can enable via LazLogger (you may have to add the unit), and then on either with LazLoggers command line (wiki on LazLogger / and/or similar example at https://wiki.lazarus.fr eepascal.org/GDB_Debugger_Tips#Log_info_for_debug_session ) Or by compiling with the following defined (there may be others...) FPDBG_BREAKPOINT_ERRORS FPDBG_BREAKPOINTS FPDBG_COMMANDS FPDBG_THREADS FPDBG_QUEUE ---------------------------------------------------------------------- Fred vS · 2021-11-19 19:18 Quote from: Martin_fr on November 19, 2021, 08:13:29 pmSince it is threaded, ensure to test with -dFPDEBUG_THREAD_CHECK And of course -Sa and all the bells and whistles.... For logging, you can enable via LazLogger (you may have to add the unit), and then on either with LazLoggers command line (wiki on LazLogger / and/or similar example at https://wiki.lazarus.fr eepascal.org/GDB_Debugger_Tips#Log_info_for_debug_session ) Or by compiling with the following defined (there may be others...) FPDBG_BREAKPOINT_ERRORS FPDBG_BREAKPOINTS FPDBG_COMMANDS FPDBG_THREADS FPDBG_QUEUE OK, perfect, many thanks. Write you later after deeper jump. Fre;D ---------------------------------------------------------------------- Fred vS · 2021-11-19 19:23 Quote from: ccrause on November 19, 2021, 07:41:00 pm... see the help listing for commands supported. Ho, perfect, many thanks for this. Fre;D ---------------------------------------------------------------------- Martin_fr · 2021-11-19 19:36 Oh, and please, if you got it compiling (and added the IFDEF for LINUX), create a merge request ---------------------------------------------------------------------- Fred vS · 2021-11-19 19:52 Quote from: Martin_fr on November 19, 2021, 08:36:30 pmOh, and please, if you got it compiling (and added the IFDEF for LINUX), create a merge request Ok, with pleasure but to make it compiles, I needed to comment this because in last release MemManager is read only. 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 procedure TFPDLoop.GControllerDebugInfoLoaded(Sender: TObject);begin  //TFpDwarfInfo(GController.CurrentProcess.DbgInfo).MemManager := FMemManager;end;   Also, have to change this: 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 var   GController: TDbgController = nil; implementation...initialization  GController :=  TDbgController.Create;         with this: 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 uses  ...  FpdMemoryTools,  // added this var   GController: TDbgController = nil;  Gmemmanage: TFpDbgMemManager = nil; // add this implementation initialization  GController := TDbgController.Create(Gmemmanage);    // change this And then the compiler is happy. Not sure the initialization is ok, but, while running, it seems so. Also there are some change to do to be FreeBSD compatible. Fre;D ---------------------------------------------------------------------- Martin_fr · 2021-11-19 19:56 And you should create the memmanager before creating the controller. Also add a MemReader. Those steps can be found in LazDebuggerFp.  (search for memmanager) You may not need to subclass the memreader. You may be able to use it as it comes in FpDebug. Not sure. ---------------------------------------------------------------------- Fred vS · 2021-11-19 20:13 Quote from: Martin_fr on November 19, 2021, 08:56:07 pmAnd you should create the memmanager before creating the controller. Also add a MemReader. OK, changed with this, compiler is happy: 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 var  GController: TDbgController = nil;  Gmemmanage: TFpDbgMemManager = nil;  // added this  GMemReader: TFpDbgMemReaderBase  = nil; // added this  GMemConvertor: TFpDbgMemConvertor  = nil;  // added this implementation initialization  Gmemmanage := TFpDbgMemManager.Create(GMemReader, GMemConvertor) ; // added this  GController :=  TDbgController.Create(Gmemmanage); Quote from: Martin_fr on November 19, 2021, 08:56:07 pmThose steps can be found in LazDebuggerFp.  (search for memmanager) You may not need to subclass the memreader. You may be able to use it as it comes in FpDebug. Not sure. OK, I will jump into this asap. Thanks for your light Martin. Fre;D ---------------------------------------------------------------------- Fred vS · 2021-11-19 20:27 Re-hello. Ok, compiles, runs also answer to command "run" but after each "continue" there is a error message, but all is still working. And when closing the program to debug, this is show, like wanted QuoteFPD>continue Process ended with exit-code 0. So maybe gdb should be used to debug fpd. Did not help. Or do you have a idea about that unknown exception code 14 ? QuoteFPD>continue ===   [$00007FBEB4A3C3FF] ??? ===   [$00007FBEB4A3C3FF]         483D00F0FFFF    cmp rax,$FFFFF000   [$00007FBEB4A3C405]                 7731    jnbe +$31   [$00007FBEB4A3C407]               4489C7    mov edi,r8d   [$00007FBEB4A3C40A]             89442408    mov [rsp+$08],eax   [$00007FBEB4A3C40E]           E8CD19F9FF    call -$0006E633   [$00007FBEB4A3C413]             8B442408    mov eax,[rsp+$08] Program raised exception class 'External: Unknown exception code 14'. FPD> ---------------------------------------------------------------------- Fred vS · 2021-11-19 21:25 Quote from: Martin_fr on November 19, 2021, 08:36:30 pmOh, and please, if you got it compiling (and added the IFDEF for LINUX), create a merge request Hello. Included in zip attach  fpd.lpr, fpdglobal.pas and fpdloop.pas that make compiler happy for Unix OS too. Running fpd is ok,  run + step  command work but I get a error message after each continue ( error code 14 ). But it dont seems to affect the continuation of the debug. Fre;D ---------------------------------------------------------------------- Fred vS · 2021-11-19 23:26 Quoteauthor=Fred vS link=topic=57235.msg425502#msg425502 date=1637353652] Or do you have a idea about that unknown exception code 14 ? Yes, I have a idea, it is defined in /rtl/linux/signal.inc and it is SIGALRM   = 14 So was added in fpdbglinuxclasses.pas      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       SIGALRM:  // this added        begin        TDbgLinuxThread(AThread).FExceptionSignal:=SIGALRM;        result := deInternalContinue;          end;      SIGPIPE:   // this added too, was missing        begin        TDbgLinuxThread(AThread).FExceptionSignal:=SIGPIPE;        result := deInternalContinue;          end; (maybe SIGALRM should raise something else than result := deInternalContinue;, maybe something more detailed.) Anyway with that code everybody is happy, the compiler, fpd and the user that has a working fast, out-of-the-box nice debugger full Pascal. Tested command run, step, continue, quit all are working ok. Now I have to code with lot of bugs to test that wonderful fpd. Included all the modified files in attachment. Fre;D ---------------------------------------------------------------------- Fred vS · 2021-11-20 00:06 Allez, the last for tonight, after I let you in peace. I forced myself to create a horrible bug in the test program: 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 procedure tmainfo.onac(const sender: TObject);varx  : integer = 0;y : integer;beginy := 10 div x;end; Yes, it is a bad bug.  But, thanks to fpd : Quotered@fredvs ~> /home/fred/fpdebug/fpd /home/fred/demo_mse/aatest/test FPDebugger on Linux for x86_64 (2021/11/20 00:01:39 FPC: 3.2.2) Copyright (c) 2006-2009 by Marc Weustink starting.... Using file: /home/fred/demo_mse/aatest/test FPD>run FPD>continue === /home/fred/demo_mse/aatest/main.pas 45:13 ONAC   [$0000000000465830+17] y := 10 div x; ===   [$0000000000465841]               48F7F9    idiv rcx   [$0000000000465844]                   C3    ret   [$0000000000465845]                 0000    add [rax],al   [$0000000000465847]                 0000    add [rax],al   [$0000000000465849]                 0000    add [rax],al   [$000000000046584B]                 0000    add [rax],al Program raised exception class 'External: Unknown exception code 8'. FPD>q Quitting ... Killing application ... Process ended with exit-code 0. fred@fredvs ~> And fpd shows the right line/row on the right unit. But External: Unknown exception code 8' shows too that some other signal like SIGFPE = 8 should be added too. Anyway, many WOW to fpd developers. [EDITED] Added zip of changed files, included missing signals: fpd.lpr, fpdglobal.pas, fpdloop.pas are in /lazarus- main/components/fpdebug/app/fpd/ and fpdbglinuxclasses.pas is in /lazarus-main/components/fpdebug And here the binary of fpd for Linux 64 bit compiled with fpc 3.2.2. https://github.com/fredvs/attach/files/7573771/fpd_linux_amd64.zip Fre;D [LAST EDIT] Note that fpd binary in attachment was compiled without optimization. With -O2 there is that error message with command "run": Quotefred@fredvs ~> /home/fred/fpdebug/fpd /home/fred/demo_mse/aatest/test FPDebugger on Linux for x86_64 (2021/11/20 05:01:52 FPC: 3.2.2) Copyright (c) 2006-2009 by Marc Weustink starting.... Using file: /home/fred/demo_mse/aatest/test FPD>run Exception at 000000000046CD2C: EAssertionFailed: TFpThreadWorkerQueue.TFpDbgTypedFifoQueue.PushItem: Result (fpdbgutil.pp, line 900). FPD> [VERY LAST EDIT] Compiling with -O2 and fpc 3.2.2 gives error with command "run" (see previous edit). But compiling  with -O2 and fpc 3.3.1 gives NO  error with command "run". Always finish with good news.  This one, I really need to go to bed. ---------------------------------------------------------------------- Martin_fr · 2021-11-20 08:19 Quote from: Fred vS on November 20, 2021, 01:06:09 am[VERY LAST EDIT] Compiling with -O2 and fpc 3.2.2 gives error with command "run" (see previous edit). But compiling  with -O2 and fpc 3.3.1 gives NO  error with command "run". https://forum.lazarus.freepascal.org/index.php/topic,57021.msg425180.h tml#msg425180 ---------------------------------------------------------------------- Martin_fr · 2021-11-20 08:24 The extra SIG.... handling would/should best be reported on the bugtracker. So they will not be forgotten. Ideally the zip should also be attached to an issue / not sure how soon I will get to it. Are those based on "git main", or on the recent 2.2RC ? Since lots have changed since 2.0.x ---------------------------------------------------------------------- ccrause · 2021-11-20 09:01 Quote from: Fred vS on November 20, 2021, 12:26:27 am(maybe SIGALRM should raise something else than result := deInternalContinue;, maybe something more detailed.) Not all POSIX signals are exceptions.  For example SIGALRM is generated by setting an alarm.  In this case I would assume the signal should be ignored by the debugger (deInternalContinue like you have done) so that the application can handle it. ---------------------------------------------------------------------- ccrause · 2021-11-20 10:16 Quote from: Fred vS on November 20, 2021, 01:06:09 amBut External: Unknown exception code 8' shows too that some other signal like SIGFPE = 8 should be added too. It is not clear to me whether all exceptions should be caught and program flow interrupted (by default) or not.  For instance the RTL installs an exception handler that maps from various OS mechanisms to runtime errors.  LazDebuggerFP installs some breakpoints to catch calls to these handlers (https://gitlab.com/freepascal.org/lazarus/laz arus/- /blob/main/components/lazdebuggers/lazdebuggerfp/fpdebugdebugger.pas#L 2327). If all exception signals are intercepted and program flow interrupted by the debugger, it becomes annoying because a single exception get trapped at two different places, which mostly just interrupts the debugging process. So my preference would be to continue through most signals, except if the debugger state needs to be updated (SIGTRAP, SIGKILL, SIGSTART, SIGCHLD etc.) - and give the user the option to activate break points for FPC_RUNERROR, FPC_BREAK_ERROR and so forth. However, the debugger (fpd, or the debugger you want to create based on this) needs to set some rules to define the expected behaviour if an unexpected exception is encountered.  Note that not all this logic should sit in fpdebug, since that would affect all debuggers using fpdebug.  Anyway, this is my opinion only, Martin and others (Marc, Joost?) may have other design goals in mind. ---------------------------------------------------------------------- Martin_fr · 2021-11-20 10:25 Quote from: ccrause on November 20, 2021, 11:16:41 amFor instance the RTL installs an exception handler that maps from various OS mechanisms to runtime errors.  LazDebuggerFP installs some breakpoints to catch calls to these handlers (https://gitlab.com/freepascal.org/lazarus/laz arus/- /blob/main/components/lazdebuggers/lazdebuggerfp/fpdebugdebugger.pas#L 2327). If all exception signals are intercepted and program flow interrupted by the debugger, it becomes annoying because a single exception get trapped at two different places, which mostly just interrupts the debugging process. Actually, IIRC, RunErrors are only made exceptions, if "SysUtils" is in the uses. 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 unit SysUtils;...Procedure InitExceptions;begin...  ErrorProc:=@RunErrorToExcept;... Initialization  InitExceptions;     { Initialize exceptions. OS independent }  That said, this could be improved. - config - smart detection / auto skip exception, if created by run-error But that is an entirely different topic.... ---------------------------------------------------------------------- ccrause · 2021-11-20 11:33 @Fred Vs: I've created a git branch for collecting some of the modifications you discussed in this thread: https://gitlab.com/ccrause/lazarus/-/commits/fpd/ You are welcome to join this repository if you want to add your work/modifications to this branch.  Or clone and continue separately if you don't want the drag of cooperation. My main aim is to collect useful ideas, even if you don't submit a request to merge. ---------------------------------------------------------------------- Fred vS · 2021-11-20 13:10 Quote from: Martin_fr on November 20, 2021, 09:24:53 amThe extra SIG.... handling would/should best be reported on the bugtracker. So they will not be forgotten. Ideally the zip should also be attached to an issue / not sure how soon I will get to it. Are those based on "git main", or on the recent 2.2RC ? Since lots have changed since 2.0.x Hello Martin I did use last commit of https://gitlab.com/freepascal.org/lazarus/lazarus/-/tree/main Quote from: ccrause on November 20, 2021, 09:24:53 am]Not all POSIX signals are exceptions.  For example SIGALRM is generated by setting an alarm.  In this case I would assume the signal should be ignored by the debugger (deInternalContinue like you have done) so that the application can handle it. Hello Ccrause. Yes, it is the reason why for SIGALRM and SIGFPE, the result := deInternalContinue;  Quote from: ccrause on November 20, 2021, 09:24:53 am]]@Fred Vs: I've created a git branch for collecting some of the modifications you discussed in this thread: https://gitlab.com/ccrause/lazarus/-/commits/fpd/ You are welcome to join this repository if you want to add your work/modifications to this branch.  Or clone and continue separately if you don't want the drag of cooperation. Ok, thanks, I will surely visit you. Fre;D ---------------------------------------------------------------------- Fred vS · 2021-11-20 14:50 Quote from: ccrause on November 20, 2021, 12:33:56 pm@Fred Vs: I've created a git branch for collecting some of the modifications you discussed in this thread: https://gitlab.com/ccrause/lazarus/-/commits/fpd/ You are welcome to join this repository if you want to add your work/modifications to this branch.  Or clone and continue separately if you don't want the drag of cooperation. My main aim is to collect useful ideas, even if you don't submit a request to merge. Hello Ccrause. I added some comments in your commits. Fre;D ---------------------------------------------------------------------- ccrause · 2021-11-20 16:32 Quote from: Fred vS on November 20, 2021, 03:50:22 pmI added some comments in your commits. Thank you, comments included (well some of them, I have to leave some fun for you  ). I just want to show that a bit of cross debugging is also possible (although not fully functional): Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i ~/lazarus/gitlab2/components/fpdebug/app/fpd$ ./bin/x86_64-linux/fpd ~/fpc/fpc-avr/src/examples/test/test.elf FPDebugger on Linux for x86_64 (2021/11/20 18:05:56 FPC: 3.2.2)Copyright (c) 2006-2009 by Marc WeustinkStarting...Using file: /home/christo/fpc/fpc- avr/src/examples/test/test.elfFPD>rDebug information loaded.  Machine type: mtAVR8  OS: osEmbeddedFPD>b test.pp:5Breakpoint 1 added at address .FPD>cBreakpoint reached at .===/home/christo/fpc/fpc- avr/src/examples/test/test.pp 5:12 dummy  [$000000000000009E+26]   PORTB := x;===  [$00000000000000B8]                 2A81    ldd r18, Y+2  [$00000000000000BA]                 3B81    ldd r19, Y+3  [$00000000000000BC]                 F901    movw r30, r18  [$00000000000000BE]                 0080    ld r0, Z  [$00000000000000C0]                 05B8    out $05, r0  [$00000000000000C2]                 CC5F    subi r28, $FCFPD>show c  Callstack: $00000000000000B8 /home/christo/fpc/fpc- avr/src/examples/test/test.pp:5 $00000000000000E4 /home/christo/fpc/fpc-avr/src/examples/test/test.pp:13This of course needs an emulator or hardware debugger of some sort to run the AVR code. ---------------------------------------------------------------------- Fred vS · 2021-11-20 16:49 Quote from: ccrause on November 20, 2021, 05:32:24 pmQuote from: Fred vS on November 20, 2021, 03:50:22 pmI added some comments in your commits. Thank you, comments included (well some of them, I have to leave some fun for you  ). By the way, I am very impressed by fpd. Compiled with fpc 3.3.1. Linux 64 bit, with -O2 -XX -CX -Xs parameter, the size of the debugger fully working as stand-alone, without any dependencies is 1.2 mega ! So little that Lazarus forum accepts the zipped binary in attachment ( 440 K !) Fre;D ---------------------------------------------------------------------- Fred vS · 2021-11-20 23:18 Quote from: Martin_fr on November 19, 2021, 08:36:30 pmOh, and please, if you got it compiling (and added the IFDEF for LINUX), create a merge request Hello Martin. Are you open to improvements ( needed and clever ) or do you prefer that I just make it work ? Ccrause did a fork dedicated to fpd: https://gitlab.com/ccrause/lazarus/-/commits/fpd/ . There we shared some ideas but of course the advice of the creators is imperative before to even envisage to change anything. Fre;D ---------------------------------------------------------------------- Martin_fr · 2021-11-21 07:16 Open to new ideas. Depending on the scope, it may be worth discussing them first (not discouraged, but need to be made to fit...). 1) Improving fpd within the fpd sources. E.g. adding new commands -> great 2) adding extended features, such a scripting to fpd -> to be discussed. Good idea, but it may be outside the scope of what should be in a sample app folder. 3) Adding to the core FpDebug. To be discussed, so it goes with future plans for the package. ---------------------------------------------------------------------- ccrause · 2021-11-21 08:16 Quote from: Martin_fr on November 21, 2021, 08:16:44 amOpen to new ideas. Depending on the scope, it may be worth discussing them first (not discouraged, but need to be made to fit...). 1) Improving fpd within the fpd sources. E.g. adding new commands -> great One philosophy to consider is to align fpd commands with gdb.  For me it is confusing that some commands work more or less just like gdb (step, next, break), while others e.g. run have a different meaning (initalize debugger vs. start new instance of debuggee).  Here my suggestion/preference is that implemented commands should conform (in basic use at least) to the gdb meaning. Quote2) adding extended features, such a scripting to fpd -> to be discussed. Good idea, but it may be outside the scope of what should be in a sample app folder. Agreed Quote3) Adding to the core FpDebug. To be discussed, so it goes with future plans for the package. The only change I am thinking of is to expose the breakpoint address property so that fpd can read and print that information for breakpoints. ---------------------------------------------------------------------- Martin_fr · 2021-11-21 09:16 Quote from: ccrause on November 21, 2021, 09:16:43 amQuote from: Martin_fr on November 21, 2021, 08:16:44 amOpen to new ideas. Depending on the scope, it may be worth discussing them first (not discouraged, but need to be made to fit...). 1) Improving fpd within the fpd sources. E.g. adding new commands -> great One philosophy to consider is to align fpd commands with gdb.  For me it is confusing that some commands work more or less just like gdb (step, next, break), while others e.g. run have a different meaning (initalize debugger vs. start new instance of debuggee).  Here my suggestion/preference is that implemented commands should conform (in basic use at least) to the gdb meaning. One could equally as well demand lldb, or gdb-mi. I kind of agree however, that an entire new set of commands, is the worst. So going with gdb based is ok. Ideally different command sets could be loaded.... I also had a quick look at FpdServer. There are similarities Fpd uses a TStringList, and does 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   MCommands.AddCommand(['help', 'h', '?'], @HandleHelp, 'help []: Shows help on a command, or this help if no command given'); FpdServer uses "TFpDebugThreadCommandList = class(TFPList)" and does 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   TFpDebugT hreadCommandList.instance.Add(TFpDebugThreadQuitDebugServerCommand); Maybe some code could be shared?  (That would need a new package "FpDebugAppTools" ("..Utils") or similar?   "FpDebugDebuggerTools" seems odd. Quote from: ccrause on November 21, 2021, 09:16:43 amQuote3) Adding to the core FpDebug. To be discussed, so it goes with future plans for the package. The only change I am thinking of is to expose the breakpoint address property so that fpd can read and print that information for breakpoints. Hm, shouldn't fpd already have this? Since it did set it? Not looked yet, but probably ok to expose. However => Should be exposed as a list. (and list only) A breakpoint can have several addresses. (For example generics can generate lots of addresses for each specialization). On that topic: Currently 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 AddBreak(const AFileName: String; ALine: Cardinal; AnEnabled: Boolean = True): TFpInternalBreakpoint; translates the line once to an address and that is it. This needs to change. If libraries are loaded, breakpoints should be able to update (they may have a flag, if they should) Anyway that is for the future. Only point about it is, that there may then be a callback "OnAddressListChanged" or similar... ---------------------------------------------------------------------- ccrause · 2021-11-21 09:47 Quote from: Martin_fr on November 21, 2021, 10:16:26 amQuote from: ccrause on November 21, 2021, 09:16:43 amQuote3) Adding to the core FpDebug. To be discussed, so it goes with future plans for the package. The only change I am thinking of is to expose the breakpoint address property so that fpd can read and print that information for breakpoints. Hm, shouldn't fpd already have this? Since it did set it?I propose to use the existing functionality in fpdebug to handle internal details of creating breakpoints, see !50. So fpd calls TDbgProcess.AddBreak to create the BP.  On success a TFpInternalBreakpoint reference is returned.  So fpd now only knows what is published by TFpInternalBreakpoint. QuoteNot looked yet, but probably ok to expose. However => Should be exposed as a list. (and list only) A breakpoint can have several addresses. (For example generics can generate lots of addresses for each specialization). Yes, will push something if !50 is accepted. ---------------------------------------------------------------------- Martin_fr · 2021-11-21 10:16 Quote from: ccrause on November 21, 2021, 10:47:53 amI propose to use the existing functionality in fpdebug to handle internal details of creating breakpoints, see !50. So fpd calls TDbgProcess.AddBreak to create the BP.  On success a TFpInternalBreakpoint reference is returned.  So fpd now only knows what is published by TFpInternalBreakpoint. QuoteYes, will push something if !50 is accepted. I don't see why returning the internal BreakPoint? It does not actually add any new public data. (except for a constructor, and that should stay internal) In fact, I have to find out why some of those functions already return internal classes. And why WatchPoints contain non-overridden abstract methods .... (There may need to be a further base class...) As for breakpoints. TFpDbgBreakpoint already has "function HasLocation". It could get abstract functions/properties - LocationCount - Location[n]  // this name currently conflicts with the array / but for public access it must be a read only property ---------------------------------------------------------------------- ccrause · 2021-11-21 11:46 Quote from: Martin_fr on November 21, 2021, 11:16:56 amQuote from: ccrause on November 21, 2021, 10:47:53 amI propose to use the existing functionality in fpdebug to handle internal details of creating breakpoints, see !50. So fpd calls TDbgProcess.AddBreak to create the BP.  On success a TFpInternalBreakpoint reference is returned.  So fpd now only knows what is published by TFpInternalBreakpoint. QuoteYes, will push something if !50 is accepted. I don't see why returning the internal BreakPoint? It does not actually add any new public data. (except for a constructor, and that should stay internal) fpd currrently has its own breakpoint list which stores references to created breakpoints.  This can probably be removed in favour of TDbgProcess.FBreakpointList, but this is not exposed so listing or deleting breakpoints are not directly possible via this route. QuoteAs for breakpoints. TFpDbgBreakpoint already has "function HasLocation". It could get abstract functions/properties - LocationCount - Location[n]  // this name currently conflicts with the array / but for public access it must be a read only property Yes, this will help in exposing information after adding say a breakpoint based on a line number in a file. ---------------------------------------------------------------------- Martin_fr · 2021-11-21 12:12 Quote from: ccrause on November 21, 2021, 12:46:55 pmfpd currrently has its own breakpoint list which stores references to created breakpoints.  This can probably be removed in favour of TDbgProcess.FBreakpointList, but this is not exposed so listing or deleting breakpoints are not directly possible via this route. ok, yes: TDbgProcess could have BreakpointCount BreakPoint[n]  => return TFpDbgBreakpoint WatchPointCount WatchPoint[n]  => needs the clean up of the class structure.... Sorry, at the moment replies are rather cursory. More depth when I find some time. ---------------------------------------------------------------------- Fred vS · 2021-11-21 16:18 Quote from: Martin_fr on November 21, 2021, 10:16:26 am... I kind of agree however, that an entire new set of commands, is the worst. So going with gdb based is ok. ... Hello Martin. Imho, it would be great if fpd could become gdb compatible. Afaik, fpd can debug also binaries not compiled with fpc. I dont know if it could be possible to make fpd enough compatible with gdb so that all other applications that use gdb could choose fpd vs gdb without any change (apart change the name+path of the debugger used). In that case even Geany could use fpd out-of-the-box. Fre;D ---------------------------------------------------------------------- af0815 · 2021-11-21 16:39 Why ? Why should fpd a monster like gdb. fpdebug should be lightweigted and special for pascal. Why should it be pressed in the corsette of gdb ? You can change the interfaces of geany too, to meke it compatible, not of fpdebug. ---------------------------------------------------------------------- Martin_fr · 2021-11-21 16:55 Quote from: Fred vS on November 21, 2021, 05:18:08 pmAfaik, fpd can debug also binaries not compiled with fpc. Generally, yes.... QuoteI dont know if it could be possible to make fpd enough compatible with gdb so that all other applications that use gdb could choose fpd vs gdb without any change (apart change the name+path of the debugger used). That wont be that easy. And I don't think it fits into the space or target of fpd. Making the existing command have the same NAMES as gdb, may be do- able. Even adding mi versions of it. But then.... - Gdb has plenty of config/options that can be set. Not happening. - The input of the command name is on thing.   The parsing of expressions is another. FpDebug expects Pascal, not C.    Yes, a new Parser could be added. - The output: FpDebug prints pascal..... Not C, Not MI-data. And I am sure more details would emerge... ---------------------------------------------------------------------- Fred vS · 2021-11-21 17:06 Quote from: af0815 on November 21, 2021, 05:39:39 pmWhy ? Why should fpd a monster like gdb. fpdebug should be lightweigted and special for pascal. Why should it be pressed in the corsette of gdb ? You can change the interfaces of geany too, to meke it compatible, not of fpdebug. Hello. About your 3 "Why ?". First we are talking about fpd, a console application that uses some fpdebug code. Second, there is no question to blow-up fpd, it is already (nearly) perfect and uses quasi all the same commands as gdb. Third very few things will be needed to change in fpd to be mostly gdb compatible for external programs that use it, like Geany. ---------------------------------------------------------------------- Fred vS · 2021-11-21 17:30 Quote from: Martin_fr on November 21, 2021, 05:55:47 pmQuote from: Fred vS on November 21, 2021, 05:18:08 pmAfaik, fpd can debug also binaries not compiled with fpc. Generally, yes.... QuoteI dont know if it could be possible to make fpd enough compatible with gdb so that all other applications that use gdb could choose fpd vs gdb without any change (apart change the name+path of the debugger used). That wont be that easy. And I don't think it fits into the space or target of fpd. Making the existing command have the same NAMES as gdb, may be do- able. Even adding mi versions of it. But then.... - Gdb has plenty of config/options that can be set. Not happening. - The input of the command name is on thing.   The parsing of expressions is another. FpDebug expects Pascal, not C.    Yes, a new Parser could be added. - The output: FpDebug prints pascal..... Not C, Not MI-data. And I am sure more details would emerge... Yes there are obstacles, of course. But it can be done step by step, fpd uses already nearly the same command names as gdb. If it is ok to already keep the same command name as gdb, it will be more easy for people that uses gdb to use fpd. I know that there are lot of possible options in gdb but for simple mortal like me, till now, I only use that command: 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 > gdb theprogramtocheck And then run, continue, step, next and quit and those commands are already defined in fpd. And about parser of other languages, of course but I did not think about that yet. To have already a standalone command-line debugger for my Pascal binaries that would not oblige me to install monsters like gdb, for example on a Rpi, makes me happy. And the challenge to make fpd run with Geany ( and ideU too for example  ) is do-able. ---------------------------------------------------------------------- Fred vS · 2021-11-21 17:48 Quote from: Fred vS on November 21, 2021, 06:30:57 pmAnd the challenge to make fpd run with Geany ( and ideU too for example  ) is do-able. Even more: Challenge to make fpd run with Lazarus, without changing anything in Lazarus code, only the path-name of the gdb debugger.  [EDIT] Please consider this not to try to concurrence fpdebug integrated in Lazarus that is, of course, much more efficient that using a external program (like gdb or fpd). fpd, imho, is focused on OS that does not have WidgetSet installed and cannot run Lazarus IDE. ---------------------------------------------------------------------- af0815 · 2021-11-21 19:53 fpd should focussed on pascal and not to mimic gdb with the wrong focussed interfaces. fpdebug is IMHO on the rigth way NOT to use gdb compatibility and use a pascal way. It will be easier for people who knows gdb to change, but if fpd is gdb compatible it will be only a more or less fork. And the major differences from C style to Pascalstyle will be lost. I think, if you want to debug a pascal program it is the best you use a real pascl style debugger. I have seen on QNAP Nas it is a hell to work with gdb direct and it C like infomations. ---------------------------------------------------------------------- ccrause · 2021-11-21 20:33 Quote from: af0815 on November 21, 2021, 08:53:34 pmfpd should focussed on pascal and not to mimic gdb with the wrong focussed interfaces. fpdebug is IMHO on the rigth way NOT to use gdb compatibility and use a pascal way. I agree with the sentiment to not blindly clone the gdb interface. However there are certain actions which are virtually universal in debuggers like step, continue, manage break points and so forth. My preference is that, where convenient, follow an existing convention. But, a hex address in the Pascal world starts with a $, so this should stay. ---------------------------------------------------------------------- Martin_fr · 2021-11-21 21:00 In general Terms: The fpd example project is and will be for the use with Pascal. Pascal/Language agnostic commands can be based on gdb syntax.E.g Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i b file:line However, gdb has some input forms that I would prefer not to burden on new users. Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i break func if a = 10That should use the extended to match the idea from https://sourceware.org/gdb/current/onlinedocs/gdb/Explicit- Locations.html#Explicit-Locations (lldb afaik also use -options) Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i break -function func -cond a=10 (or quotes, if there must be spaces) Also interactive querying should be optional (i.e "fpd --iact" to enable) https://sourceware.org/gdb/current/onlinedocs/gdb/Ambiguous- Expressions.html#Ambiguous-Expressions Ideally the "command interpreter" is kept exchangeable. So different ones can be used. Then the default can be moderate, and the user can load a command set: "fpd --cmd=foo" As for none Pascal: The entire core of FpDebug is language agnostic. It is Dwarf2, and parts of Dwarf3 and more Dwarf to come. The core has an optional extension, to detect FPC generated info, and to "fix" fpc oddities. Pascal happens in 2 places, and both are plug-able, each just one unit: - the parser - the printer Shipping a parser/printer for C would not be a problem. It would hardly take much space, and using/compiling it could be entirely optional "$IFDEF". The pascal parser also is a bit lenient. It does for example accept 0xabc123. This token can not appear in Pascal, and it therefore is clear what the user wanted. ---------------------------------------------------------------------- af0815 · 2021-11-21 21:04 thx to martin for the information ---------------------------------------------------------------------- Fred vS · 2021-11-21 21:07 Quote from: af0815 on November 21, 2021, 08:53:34 pmfpd should focussed on pascal and not to mimic gdb with the wrong focussed interfaces. fpdebug is IMHO on the rigth way NOT to use gdb compatibility and use a pascal way. It will be easier for people who knows gdb to change, but if fpd is gdb compatible it will be only a more or less fork. And the major differences from C style to Pascalstyle will be lost. I think, if you want to debug a pascal program it is the best you use a real pascl style debugger. I have seen on QNAP Nas it is a hell to work with gdb direct and it C like infomations. Hello af0815. Did you already try fpd ? https://gitlab.com/freepascal.org/lazarus/lazarus/- /tree/main/components/fpdebug/app/fpd There is a Lazarus project lpi file included. Maybe you could take a look, compile, run and test it. This project was last developed in 2009 (with some commits here and there later). When I tried it last week, it did not compile and was Windows only compatible. This is the header of fpd.lpr by the original creator: Marc Weustnik: Quote----------------------------------------------------------------- ----------  fpd  -  FP standalone windows debugger  --------------------------------------------------------------------- ------  fpwd is a concept Free Pascal Windows Debugger. It is mainly used to thest  the windebugger classes, but it may grow someday to a fully functional  debugger written in pascal.  --------------------------------------------------------------------- ------  @created(Mon Apr 10th WET 2006)  @lastmod($Date$)  @author(Marc Weustink )  ********************************************************************* ****** Of course you may let it as is it. But also think positively to make it on the run for today. And following some "classical" commands used by lot of debuggers dont hurt the Pascal mood, imho. ---------------------------------------------------------------------- Fred vS · 2021-11-24 16:59 Quote from: Martin_fr on November 21, 2021, 05:55:47 pmQuoteI dont know if it could be possible to make fpd enough compatible with gdb so that all other applications that use gdb could choose fpd vs gdb without any change (apart change the name+path of the debugger used). That wont be that easy. And I don't think it fits into the space or target of fpd. Making the existing command have the same NAMES as gdb, may be do- able. Even adding mi versions of it. But then.... - Gdb has plenty of config/options that can be set. Not happening. - The input of the command name is on thing.   The parsing of expressions is another. FpDebug expects Pascal, not C.    Yes, a new Parser could be added. - The output: FpDebug prints pascal..... Not C, Not MI-data. And I am sure more details would emerge... Hello Martin. Yes, indeed, I jumped into --interpreter GDB things, not easy. QuoteMaking the existing command have the same NAMES as gdb, may be do-able. Even adding mi versions of it. I did play with fpd adapting the command name to mi version and it works. fpd responds OK to the order from Lazarus. But it is not (yet) the case of Lazarus that does not catch the answers from fpd. All this to confirm that it is absolutely doable. And that it is absolutely not in priority. Having a working stand-alone command line debugger is just perfect and mi-versions are for tomorrow. Fre;D