View Issue Details

IDProjectCategoryView StatusLast Update
0037292LazarusDebuggerpublic2020-07-08 09:48
Reporternanobit Assigned ToMartin Friebe  
PrioritynormalSeverityminorReproducibilityrandom
Status assignedResolutionopen 
Platformwin32OSWindows 
Product Version2.1 (SVN) 
Summary0037292: FpDebug: programmatic breakpoint
DescriptionAfter F9/F8, a programmatic breakpoint (windows.debugBreak(); or "asm int 3; end;")
should cause the debugger to halt at line after this breakpoint. Gdb-based debuggers support this.
Under current FpDebug, the breakpoint mostly has no impact (It worked in some older
unofficial Lazarus version, but I could not restore that exact environment to reproduce it).
Tested with latest Lazarus Trunk and FPC 3.2 (winSeh32).
TagsNo tags attached.
Fixed in Revision
LazTarget
WidgetsetWin32/Win64
Attached Files

Activities

Martin Friebe

2020-07-02 21:00

manager   ~0123719

For testing please see https://github.com/User4martin/lazarus/tree/f-fpdebug-int3
Only works with int3
not int 3
(mind the space, those generate different binary code)


Some site effects, at least with 64/32bit cross debugging, see https://forum.lazarus.freepascal.org/index.php/topic,50403.msg367937.html#msg367937

nanobit

2020-07-03 08:37

reporter   ~0123724

That's great. My testing (win32) has been successful.
Cross-debugging (beyond my installation/app) needs more testers.

Martin Friebe

2020-07-05 21:25

manager   ~0123766

I implemented a basic version in r63513
Only "int3", but not "int 3"

Also it is not enabled by default.
This is because during cross-debugging 32bit app in 64bit fpdebug, such int3 occur in ntdll.

The plan is to (someday) add detection where the int3 occurred and make the default to stop, except for occurrances in ntdll.
And except from that exceptions any occurrence in ntdll.DebugBreak.

Until then, its off by default.

nanobit

2020-07-06 09:03

reporter   ~0123768

Tested with enabled break and found this difference now: When the debugger stops (after int3),
the focus first goes to empty asm view, unlike with gdb debugger (focus stays in source editor).

Martin Friebe

2020-07-06 15:05

manager   ~0123781

r63521 should go to the source. (assuming line info available).

Note: It does stop the next line. That is because the Instruction pointer already progressed. For a user breakpoint, the IP is decremented, in order to executed the real instruction on the location. A Hardcoded Int3 is not re-executed (the app will never get to see the signal itself). So the IP is not decreased, and there is no code to simulate this for showing the location.

Not sure, but maybe In some case, when the next line is an "end" or "except" the location may be at the opening statement of that construct. That is how line info is generated.

Martin Friebe

2020-07-08 04:03

manager   ~0123809

You may notice that the debugger will pause (in asm window), if you change a breakpoint while the app is running.
To set the breakpoint the target must be paused. For that ntdll.DebugBreak (an int3) is called. And therefore the debugger pauses.

I tried some workaround: https://github.com/User4martin/lazarus/compare/f-fpdebug-hardcoded-int3-experimental?expand=1
But that needs a good deal of testing.
And review, since it now uses the fallback to inject the break (rather than the preferred method).

nanobit

2020-07-08 09:48

reporter   ~0123813

Tested (new inject method) with changing breakpoints and works as expected
(no needless showing of asm window. And breakpoints work.)

Issue History

Date Modified Username Field Change
2020-07-02 10:46 nanobit New Issue
2020-07-02 10:46 nanobit Status new => assigned
2020-07-02 10:46 nanobit Assigned To => Martin Friebe
2020-07-02 21:00 Martin Friebe Note Added: 0123719
2020-07-03 08:37 nanobit Note Added: 0123724
2020-07-05 21:25 Martin Friebe Note Added: 0123766
2020-07-06 09:03 nanobit Note Added: 0123768
2020-07-06 15:05 Martin Friebe Note Added: 0123781
2020-07-08 04:03 Martin Friebe Note Added: 0123809
2020-07-08 09:48 nanobit Note Added: 0123813