How to register debugger from package?

[Martin_fr]

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]

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.

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]

Well, Delphi debugger is quite powerful I suppose. It uses VirtualTreeView as far as I know.

[v.denis]

I have created project https://code.google.com/p/vdbg/

a very basic Debug APIs are implemented now (still no exception support)

[jwdietrich]

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

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)?

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.

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

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]

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

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]

I'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]

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)

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;


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.

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]

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]

I guess I saw it in breakpoint properties.

[v.denis]

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]

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.