Rigging a Lazarus/FPC Console Test Harness
lazarus / 12-Debugger

----------------------------------------------------------------------
Cfidicus · 2014-02-26 02:00

Lazarus Console Test Harness
----------------------------
Used for testing a console program's source code with Lazarus' GDB
debugger under FreeBSD 9.2.

# 2014-02-23  by Mark L. Rathbun (A.K.A. Cfidicus)
# System: PC-BSD/FreeBSD 9.2-RELEASE-p1 (amd64)
#         x86-64-freebsd-gtk 2
#         AMD FX-6100 Six-Core Processor
#         7.97 GB RAM
#         KDE v. 4.10.5_1, Gnome 2.3.2.1, LXDE 1.0_5
#         Lazarus v 1.0.2, Date: 2014-02-20
#         FPC v 2.6.2
#         SVN Revision: Unknown
#         GDB v7.6.1 for FreeBSD

program LazConsoleTestHarness;
begin
  ...
end.

This program, see attached, was created using Lazarus' console project
template which uses TProcess to couch a programmer's console source
code.

It successfully runs as a console app. Debugging it with gdb in
Lazarus
requires that a terminal window be opened independently of Lazarus.

Keystrokes, including Ctrl-c, performed properly within the console.

LIMITATIONS
-----------
This debugging arrangement only tested connecting a Lazarus console
program being debugged in the Lazarus IDE environment to a free
running console.  Only Readln and Writeln statements were tested. 
Other coding statements relevant to console programs were not tested,
therefore other limitations/problems are not known.

SETUP:
------
Ensure that GDB v7.6.1 is installed.

In Lazarus IDE's "Run -> Run Parameters -> Use Launching Application"
string field, this string (modified from what shipped with Lazarus)
was saved and the checkbox checked OFF, and the "Run -> Run Parameters
-> Use Display " is also checkbox checked OFF.

KDE's konsole was launched, and within it, the command tty was issued
to find out which console it was. In this test it was /dev/pts/3

Next, this string was placed in Lazarus'
Tools->Options...->Debugger->General ConsoleTty field, and saved.

A special, separately compiled console program is launched in konsole
running on /dev/pts/3 using this at the commandline:

          ./nextcrewl >/dev/pts/3 </dev/pts/3

Here's the code for nextcrewl which is compiled with debugging info ON
and all optimizations OFF (not strictly necessary):

Code: [Select]program nextcrewl;
// Non-evaluating xterm console read-write loop
{$mode objfpc}{$H+}
uses
  SysUtils;
var
  sInput: String;
  iLoop: longint = 0;
begin
  repeat
    Write(IntToStr(iLoop) +'$ '); ReadLn;
    Inc(iLoop);
  until False;
end;

RUNNING AND TESTING:
--------------------
While nextcrewl is running in konsole on /dev/pts/3 Lazarus is started
with this console app (which was made by using Lazarus' Console
project template found under "Project -> New Project... -> Console
application").

Set breakpoints and step through this source code. Respond to Readln
and Readln(s) statements by entering keystrokes in konsole
(/dev/pts/3), completed with the ENTER key.

RESULTS:
--------
Lazarus' GDB hooks into the nextcrewl running on /dev/pts/3 where
nextcrewl is displaying "0$ " in konsole and waits for input for its
first pass on its Readln statement.

While nextrewl is waiting on its Readln statement, GDB hooks to it as
a result of starting this program, LazConsoleTestHarness, via RUN, F9,
F8, or F7.

GDB displays a hook message in konsole, which looks like this:

Code: [Select]0$ &"warning: GDB: Failed to set controlling terminal:
Operation not  permitted\n

Writeln('literal') statements in LazConsoleTestHarness are displayed
on
/dev/pts/3, completed with a new line (\n).  These cause the display
in konsole to look something like this:

Code: [Select][mrathbun@kti-a61~/tests]$ ./nextcrewl >/dev/pts/3
</dev/pts/3
0$ &"warning: GDB: Failed to set controlling terminal: Operation not
permitted\n"
Lazarus Console Test Harness - this whole string is a Writeln from
LCTH.
This itself is a keyed-in message in response to a Readln from LCTH.
     <-- After hitting ENTER, the cursor sits here.

The /dev/pts/3 cursor is shown where indicated above. Note that this
is NOT showing a newly issued prompt from nextcrewl, which is still
stopped on its first Readln. However, the Writeln statements are
executed within LazConsoleTestHarness and execution returns
immediately to the next statement within LazConsoleTestHarnes.

When LazConsoleTestHarness executes a Readln or Readln(sVar)
statement, the GDB debugger suspends Lazarus while
LazConsoleTestHarness waits to receive input from /dev/pts/3.

Here's a sample of a complete /dev/pts/3 konsole session:

Code: [Select][mrathbun@kti-a61~/tests]$ ./nextcrewl >/dev/pts/3
</dev/pts/3                                                          
                             
0$ &"warning: GDB: Failed to set controlling terminal: Operation not
permitted\n"
Lazarus Console Test Harness - wl step 0.0 - Writeln('literal') from
LazConsoleTestHarness.
wl step 1.0 - Writeln('literal') from LCTH.
wl step 2.0 - Writeln('literal') from LCTH. No Readln statements yet
sent from LCTH.
keyed input for LCTH Readln; 1.
1$    <-- here note that control didn't pass back to LCTH, but was
gobbled by the first nextcrewl Readln; and is sitting on its second
pass Readln;
keyed input for LCTH Readln; 2.
wl step 3.0 - Writeln('literal') from LCTH following two Readln
statements sent from LCTH.
keyed input for LCTH Readln(s); 3.
*keyed input for LCTH Readln(s); 3.*
keyed input for LCTH Readln; 4.
2$    <-- here again note that control didn't pass back to LCTH, but
was gobbled by the second nextcrewl Readln; and is sitting on its
third pass Readln;
wl step 4.0 - Writeln('literal') from LCTH following Readln(s);
Writeln('*',s,'*'); Readln;
Hello World! - wl step 5.0 - Writeln('literal') from LCTH
keyed input for LCTH Readln; 5.
wl step 6.0 - Writeln('literal') from LCTH following Readln;
*First you say hello, and then you say good-bye.*
keyed input for LCTH Readln(s); 6.
*keyed input for LCTH Readln(s); 6.*
wl step 7.0 - Writeln('literal') from LCTH following s assignment;
Writeln('*',s,'*'); Readln(s); Writeln('*',s,'*');
Good-bye cruel World! - wl step 5.0 -  Writeln('literal') from LCTH
keyed input for LCTH Readln(s); 7.
*keyed input for LCTH Readln(s); 7.*
wl step 8.0 - Writeln('literal') from LCTH following Readln(s);
Writeln('*',s,'*');
Good-bye, Lazarus. Go back to sleep... - wl step 9.0 - 
Writeln('literal') from LCTH
keyed input for LCTH Readln(s); 8.
*keyed input for LCTH Readln(s); 8.*
wl step 10.0 - Writeln('literal') from LCTH following Readln(s);
Writeln('*',s,'*');
Coup d' grace. - wl step 11.0 -  Writeln('literal') from LCTH
^C
[mrathbun@kti-a61~/tests]$ exit

Readln and Readln(sVar) statments in LCTH are intermittently
problematic in that after keying input for LCTH Readln, then pressing
ENTER, it seems that the debugger does not retain control of
/dev/pts/3, but loses it to nextcrewl, which gobbles up the input with
its Readln statement, displays its prompt for the next iteration, then
pauses on its next Readln, waiting for keyed input.

Responding to the nextcrewl Readln with (or without typed input)
followed by an ENTER key causes the debugger to steal the input and
return control back to LCTH before nextcrewl's Readln is fed the
input, resulting in nextcrewl remaining paused waiting for input.

At this point debugging execution continues in LCTH, utilizing
/dev/pts/3 for Writeln output.  When a Readln within LCTH is executed,
input focus consistently shifts to /dev/pts/3, but pressing ENTER
after keyed input may or may not return focus and control back to the
LCTH debugging session. Focus and control, as explained above, might
drop into nextcrewl until it receives an ENTER keystroke in response
to its Readln.

It would be an improvement if somehow the debugger could be made to
consistently return control back to LCTH.

What could be the cause of and the fix to this problem?

There may be yet other unknown problems with this technique, but as it
is, it does work to debug console apps, albeit in a stumbling way.

Thanks for your replies.

----------------------------------------------------------------------
Martin_fr · 2014-02-26 02:22

About your console redirect. This used to be necessary in older
versions. And still is on MAC unfortunately.  I dont know if it is
needed on  Freebsd.

On linux, Lazarus has a debug window "console output" (Menu: View >
Debug Windows > Console output)
(This only works, if you remove all the tty settings)

Have you checked if that exists/works on Freebsd? (I do not know, I
newer tested)

Though this build in Window does not have any terminal emulation, just
raw in/output.

Some of the info  (but nothing that you did not describe in more
detail) is also here:
http://wiki.lazarus.freepascal.org/Debugger_Console_App

----------------------------------------------------------------------
Cfidicus · 2014-02-26 02:29

Unfortunately, under FreeBSD, Lazarus has no debug window "console
output" (Menu: View > Debug Windows > Console output), therefore this
technique is necessary.

----------------------------------------------------------------------
Martin_fr · 2014-02-26 03:11

Ah yes.

Code: [Select]{$IFDEF linux} {$DEFINE DBG_ENABLE_TERMINAL} {$ENDIF}

But it may be worth testing it. The code should be similar. It is all
about the IDE creating a tty of its own.

If you want, try to define it, maybe it works.