[DONE] FpDebug feature request

[440bx]

Hello,

A big thank you to Martin_fr and everyone involved in the development of FpDebug, a good debugger is a crucial tool and FpDebug is consistently getting more and more capable .

With due credit properly given above, it would be extremely useful if FpDebug allowed inline breakpoints, i.e, int 3 instructions in the pascal code.

Currently when FpDebug finds something like this:

Code: Pascal  [Select][+][-]

1. if IsDebuggerPresent() then asm int 3 end;

an "illegal instruction" is declared and execution stops with a runtime error 216.

Related to that problem is FpDebug's behavior when it finds an int 3 in a system dll e.g, in kernel32, in that case it just ignores the int 3, just as if it wasn't there.  It would be nice if FpDebug would honor those.

The reason having FpDebug handle inline "int 3" is important is because creating _conditional_ breakpoints  using Lazarus "Breakpoint properties" has some limitations (see help topic for more info.)  If FpDebug allowed inline "int 3" then inline conditional breakpoints could be defined using the full power of Pascal and all the context information to define the condition that would trigger the breakpoint.  IOW, really powerful breakpoints (Manhattan Project breakpoints!)

The addition of this feature has become more important lately because GDB, which does handle inline "int 3", more often than not seems to not work at all in recent versions of Lazarus, e.g, v3.2, thereby eliminating the convenient and only alternative.

Thanks for reading.

[Martin_fr]

There is a setting "HandleDebugBreakInstruction" in the property grid of the FpDebug backend.
Uncheck "ignore all", and afaik it does what you want. Please test.

You can setup a FpDebug backend in your project options too, and then toggle it per project.

[440bx]

There is a setting "HandleDebugBreakInstruction" in the property grid of the FpDebug backend.
Uncheck "ignore all", and afaik it does what you want. Please test.

You can setup a FpDebug backend in your project options too, and then toggle it per project.

That's wonderful... thank you!

Now I can have my custom "Pascal-conditioned" breakpoints again... made my day!

[Martin_fr]

The reason having FpDebug handle inline "int 3" is important is because creating _conditional_ breakpoints  using Lazarus "Breakpoint properties" has some limitations (see help topic for more info.) 

This help? https://wiki.lazarus.freepascal.org/IDE_Window:_Breakpoints#Breakpoint_properties

It points out the limits for GDB... but for FpDebug?
E.g. FpDebug can do s='foo'
And if you look up intrinsics https://wiki.lazarus.freepascal.org/FpDebug-Watches-Intrinsic-Functions , there is an upper/lowercase, so you can compare :lower(s)='foo'
Or a substring.

-- EDIT: use dwarf 3

Still a conditional int3 on high frequented code is much faster...

[440bx]

This help? https://wiki.lazarus.freepascal.org/IDE_Window:_Breakpoints#Breakpoint_properties

That's the part of the Help I had read.

It points out the limits for GDB... but for FpDebug?
E.g. FpDebug can do s='foo'
And if you look up intrinsics https://wiki.lazarus.freepascal.org/FpDebug-Watches-Intrinsic-Functions , there is an upper/lowercase, so you can compare :lower(s)='foo'
Or a substring.

I remembered that FpDebug had functions such as :lower, you mentioned them in some posts here but, for some reason I didn't get to the page that listed all the FpDebug functions, that left me having to rely on the "alternative" combination of gdb and Pascal which, at least in v3.2 isn't working (I mean gdb.)

Still a conditional int3 on high frequented code is much faster...

That on one side and the fact that having the entire Pascal compiler and the units available to define the conditions is something that the debugger should not even attempt (it's a debugger, not a compiler <chuckle>)

Thank you for the link to FpDebug's intrinsic functions, that's very handy for a quick conditional breakpoint and, when the going gets tough, DebugBreak() and Pascal takes care of that situation.