Forum > Debugger
Breakpoint addition or removal
Martin_fr:
--- Quote from: MarkMLl on March 10, 2021, 09:24:14 pm ---Thanks for the update Martin. I've got a problem relating to different shared-object library behaviour in 32- and 64-bit, so knowing that is probably relevant.
--- End quote ---
Background to the problem with the breakpoint add/remove.
When the application is running, the IDE can not ask gdb to perform any task (that differs, when using gdb-server).
So when
- breakpoints are changed(properties)/added/removed
- the visible editor tab is changed, and blue dot info is needed for a file
- the pause button is pressed
Then the exe needs to be paused for a tiny moment. To do that the IDE calls a window API, to inject a int3.
When that happens the OS, invokes the debugger and provides an event code for this.
A 64 bit process (IDE) can execute that on a 32bit target. But the OS sends a different event code in that case. GDB does not understand/expect this.
So gdb will let the app execute the int3 => and that crashes. The app can also not catch it, because it happens in a thread the OS created for that.
Lazarus trunk will run an additional helper process in 32bit mode to send the signal.
FpDebug understands the different event code. So it works.
440bx:
--- Quote from: Martin_fr on March 10, 2021, 10:19:49 pm ---To do that the IDE calls a window API, to inject a int3.
<snip>
GDB does not understand/expect this.
So gdb will let the app execute the int3 => and that crashes. The app can also not catch it, because it happens in a thread the OS created for that.
--- End quote ---
Just a thought and, I don't really know if it would work but, might be worth a try. If instead of injecting an int 3 that neither GDB nor the app expect, _maybe_ suspending all the debuggee threads then have the IDE tell GDB to place the int 3 where desired. Since the debuggee is suspended, that _might_ work and the int 3 will no longer be unexpected by GDB (since it is there because _it_ placed it there.)
Martin_fr:
--- Quote from: 440bx on March 11, 2021, 02:08:52 am ---
--- Quote from: Martin_fr on March 10, 2021, 10:19:49 pm ---To do that the IDE calls a window API, to inject a int3.
<snip>
GDB does not understand/expect this.
So gdb will let the app execute the int3 => and that crashes. The app can also not catch it, because it happens in a thread the OS created for that.
--- End quote ---
Just a thought and, I don't really know if it would work but, might be worth a try. If instead of injecting an int 3 that neither GDB nor the app expect, _maybe_ suspending all the debuggee threads then have the IDE tell GDB to place the int 3 where desired. Since the debuggee is suspended, that _might_ work and the int 3 will no longer be unexpected by GDB (since it is there because _it_ placed it there.)
--- End quote ---
Suspending the threads is not going to help. While the app is running, gdb is in the "-exec-continue" command. And gdb will not accept any other commands until that finishes. So nothing can be send to gdb.
If you run gdb on a comand-line, you do ctrl-c and gdb will interrupt the app. But that does not work from the IDE. It did last on Win-95. (IIRC)
Gdb has an asynchronous command mode, where you could send the "interrupt" command (then gdb injects the int3). But that mode does only work with gdbserver, and some few special targets. Not on Windows.
You have to sent sent that int3.
Also, we have a working solution. The SVN 2.1 trunk IDE can run in 64bit, and use gdb to debug a 32bit target.
Further gdb will become more and more the option for remote debugging, embedded, and similar. Native (Win/Linux) will move to FpDebug.
-------
I just retested with gdb 9.2 => it still does not understand that code.
Gdb 10.1 introduces new errors when evaluating watches (watches that used to work, like "shortstring"). So I have not tested it. Would not help anyway.
There are rumours on stack overflow, that gdb 10 may have it fixed. But does not help, if it crashes on watches
440bx:
Martin, thank you for explaining the issues. Appreciate it.
MarkMLl:
Thanks for the detail Martin. Interesting and thought-provoking from the POV of system software design.
MarkMLl
Navigation
[0] Message Index
[#] Next page
[*] Previous page