View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0037292 | Lazarus | Debugger | public | 2020-07-02 10:46 | 2020-07-08 09:48 |
| Reporter | nanobit | Assigned To | Martin Friebe | ||
| Priority | normal | Severity | minor | Reproducibility | random |
| Status | assigned | Resolution | open | ||
| Platform | win32 | OS | Windows | ||
| Product Version | 2.1 (SVN) | ||||
| Summary | 0037292: FpDebug: programmatic breakpoint | ||||
| Description | After 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). | ||||
| Tags | No tags attached. | ||||
| Fixed in Revision | |||||
| LazTarget | |||||
| Widgetset | Win32/Win64 | ||||
| Attached Files |
| ||||
|
|
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 |
|
|
That's great. My testing (win32) has been successful. Cross-debugging (beyond my installation/app) needs more testers. |
|
|
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. |
|
|
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). |
|
|
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. |
|
|
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). |
|
|
Tested (new inject method) with changing breakpoints and works as expected (no needless showing of asm window. And breakpoints work.) |
| 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 |
