Author Topic: Suggestions and Info about gdb and terminals on Linux  (Read 304 times)


  • Administrator
  • Hero Member
  • *
  • Posts: 5768
    • wiki
Suggestions and Info about gdb and terminals on Linux
« on: May 01, 2019, 09:42:33 pm »
This is a follow up to:,45050.msg319795.html#msg319795

This should work:

Lazarus starts terminal for a wrapper .
The wrapper suspends itself, before execing the actual program.
The debugger attaches itself to the wrapper and unsuspends it, which then becomes the actual program

Alternatively, Lazarus could implement its own terminal.

I have my doubts about the wrapper. It would have to be totally invisible to the debugged target. That could easily alter its behaviour.
Not to say that then some sort of interprocess communication would be needed, so the IDE knows when it is running.
That sounds like a lot of stuff that can go wrong.
Especially since there are no guarantees how terminals will react (now or in future).
If someone wants to try it, the debugger has an attach feature.

The problem with running in a terminal (afaik) is that nowadays all terminals fork new processes for the app they run. By default gdb does not follow those. It would need investigation if that can be changed....

FpDebug may as some time get the ability to deal with this. With FpDebug, at least we will have full control over all the steps needed.

Btw there is a global option in Tools > Option > Debugger. You can specify a pty to which the app should get connected.
All you need to do is start a terminal, use the command "pty" (or tty?) to get its pty, and enter it in the IDE.

As I have told the devs but only to be boo-ed like Roman Reigns, that thing called libvte (virtual terminal)  8-)
libvte means a 3rd party dependency. And bindings.
But if someone wants to do that as a package, the required hooks can be exposed in IdeIntf (or DebuggerInf), so the package could provide a terminal.

Same about implementing a pty emulator in pascal. At this stage this requires a contributor.

Having our own terminal would be a good solution, as it would not only allow to see the output, but also to be able to display the raw stdout in a separate tab, which could help debugging even more

I am currently maintaining all the debuggers (gdb, gdbserver, gdb-ssh, gdb+fp, lldb, lldb+fp, fp). That leaves little time to write  a term emulator.
« Last Edit: May 01, 2019, 09:45:03 pm by Martin_fr »