How to register debugger from package?

[v.denis]

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]

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]

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]

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]

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]

What are your plans? fpdebug, duby, something new?

[v.denis]

Simple Windows-only debugger. Some parts of dwarf parsing I can see implemented in fpdebug.

[Martin_fr]

Simple 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]

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]

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.

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]

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]

look for ProcessStopped, that is pause, exception, breakpoint, terminated ....

[Graeme]

Simple 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]

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]

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/Entries/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.