Known Problems with Gforth 0.7

Disassembling (e.g., with see) hangs on Ubuntu

Symptoms

If you type
  see +
into Gforth, nothing happens (you can get out of this state by pressing Ctrl-D).

Fix

Perform
  sudo sysctl kernel.yama.ptrace_scope=0
To make this permanent, edit (with superuser privileges) /etc/sysctl.d/10-ptrace.conf, and change the line setting kernel.yama.ptrace_scope to set it to 0:
kernel.yama.ptrace_scope = 0

Explanation

The fix enables a feature that Ubuntu disables because they think few people need it (you are obviously one of those few), for security reasons: It disallows attaching the debugger to a non-child process. I have a hard time coming up with a realistic attack scenario against which disabling this feature defends, so disabling this feature probably does not provide much, if any additional security.

Alternative workaround

Still, if you don't want to enable the feature, an alternative is to type, within Gforth:
  ' dump is discode
This means that now dump is the "disassembler". While the output is not as nice as the output of gdb when it works, it is still better than a hanging gdb.

Known Problems with Gforth 0.6.2

(mostly about installation).

Does not build with ffcall on 64-bit systems and PPC

Symptoms

Building gforth fails with errors like:
./prim:2309: error: aggregate value used where an integer was expected
./prim:2309: error: aggregate value used where an integer was expected
./prim:2328: error: aggregate value used where an integer was expected
./prim:2328: error: aggregate value used where an integer was expected
./prim:2360: error: incompatible types in assignment

Fix

Apply the patch and build gforth as follows:
wget http://www.complang.tuwien.ac.at/forth/gforth/Patches/0.6.2-ffcall-64bit.diff &&
patch -p0 <0.6.2-ffcall-64bit.diff &&
sleep 1 &&
touch engine/*.i kernel/aliases.fs kernel/prim.fs &&
configure &&
make

Explanation

Building with ffcall on systems with buggy long longs was not catered for (it had not been tested).

Build problem on Fedora Core 1 (or any system with exec-shield)

Symptoms

The build fails with
GFORTHD="./gforth-ditc -p .:." GFORTH="./gforth-ditc --die-on-signal -p 
.:. -i kernl32l.fi -e 3 exboot.fs startup.fs arch/386/asm.fs 
arch/386/disasm.fs" ./gforthmi gforth.fi  --die-on-signal -p ".:~+:." -i 
kernl32l.fi -e 3 exboot.fs startup.fs arch/386/asm.fs arch/386/disasm.fs
data offset=32D0E0
code
in file included from *the terminal*:0
*evaluated string*:-1: images produced by different engines
...

Fix

Apply the following patch:
Index: comp-i.fs
===================================================================
RCS file: /usr/local/lib/cvs-repository/src-master/gforth/comp-i.fs,v
retrieving revision 1.14
diff -u -r1.14 comp-i.fs
--- comp-i.fs	2003/08/25 14:17:43	1.14
+++ comp-i.fs	2004/03/10 16:26:46
@@ -43,7 +43,7 @@
     if
 	." : images have the same base address; producing only a data-relocatable image" cr
     else
-	offset abs expected-offset <> abort" images produced by different engines"
+	\ offset abs expected-offset <> abort" images produced by different engines"
 	."  offset=" offset . cr
 	0 image1 i-field + ! 0 image2 i-field + !
     endif

Explanation

Data allocation varies more between the runs than it does without exec-shield.

The Windows install hangs on W95, W98, WME; gforth hangs

Symptoms

When installing Gforth from the old self-installing Windows executable (3.5MB), the install hangs when it calls gforth. However, the installation is almost complete at that point. Gforth hangs on startup, but gforth-fast, gforth-ditc, and gforth-itc work.

Fix

Install Gforth from the current self-installing Windows executable (4.2MB).

Workaround

Use gforth-itc for debugging and gforth-fast for fast execution. Note that gforth-fast will also break once you compile enough code; you can work around that by calling gforth-fast (or gforth) with the --no-dynamic option (disadvantage: a slowdown by about a factor of 2).

Explanation

mmap() was broken on Windows 9x/ME. See this Cygwin bug report.

Does not build on Suse 9.0 for i386 (possibly with other gccs >3.3)

Symptoms

gforth reports a failed assertion during installation.

Workarounds

Use the binary package. Or configure with either of
./configure no_dynamic_default=yes
./configure CC="gcc -DNDEBUG"
./configure CC="gcc -fno-reorder-blocks"
Or compile with a different compiler (gcc-2.95.* produces the best code).

Build Problems on PPC

Symptoms

The build fails with messages like:
./prim:2309: aggregate value used where an integer was expected
./prim:2328: aggregate value used where an integer was expected
./prim:2360: incompatible types in assignment
./prim:2393: incompatible types in assignment
./prim:2417: incompatible types in assignment

Workaround/Fix

Either one of these should work:

SYSTEM and SH do not work as expected on Windows and MS-DOS

Symptom

Some of the following lines produce errors:
s" dir" system \ file not found on W98SE
s" edit" system \ file not found on W98SE
s" edit.com" system \ works on W98SE
s" xcopy" system \ works (but complains about missing parameters)

Workaround

Use the following lines instead
s" command /c dir" system
s" command /c edit" system

Explanation

DIR is a builtin of command.com; EDIT is a .com file. Apparently the Cygwin system() call (called by Gforth's SYSTEM) does not invoke command.com to process the builtins and resolve .com vs. .exe file names. And it seems to be able to only append .exe (not .com) when trying to execute programs.

The singlestep debugger does not work

Fix

Apply this patch and rebuild gforth.fi by changing to the Gforth directory and performing
wget http://www.complang.tuwien.ac.at/forth/gforth/Patches/0.6.2-debug.diff
patch <0.6.2-debug.diff
make
make install
Now you can use the debugger when using the gforth-itc engine (the debugger still does not work for gforth or gforth-fast).

Callbacks from C to Forth to C again don't work

Fix

Apply the following patch with patch -p0
Index: engine/main.c
===================================================================
RCS file: /usr/local/lib/cvs-repository/src-master/gforth/engine/main.c,v
retrieving revision 1.139
retrieving revision 1.140
diff -u -r1.139 -r1.140
--- engine/main.c.old	2004/01/20 19:07:41	1.139
+++ engine/main.c	2004/04/10 00:16:55	1.140
@@ -70,8 +70,21 @@
 
 void engine_callback(Xt* fcall, void * alist)
 {
+  /* save global valiables */
+  Cell *rp = RP;
+  Cell *sp = SP;
+  Float *fp = FP;
+  Address lp = LP;
+
   clist = (va_alist)alist;
-  engine(fcall, SP, RP, FP, LP);
+
+  engine(fcall, sp, rp, fp, lp);
+
+  /* restore global variables */
+  RP = rp;
+  SP = sp;
+  FP = fp;
+  LP = lp;
 }
 #endif
 

install-info balks

See the relevant 0.6.1 section.

Known Problems when installing Gforth 0.6.1

install-info balks

Symptom

During make install, install-info complains about a non-existing directory or somesuch, and then installation stops. Such things happen with the Debian install-info, and (in a different way) with install-info from texinfo 3.9.

Fix

Use install-info from a recent texinfo (e.g., 4.2).

Workarounds

You can use either of these methods:

Printing the manual on Letter size paper

Symptom

The file doc/gforth.ps prints a little too high on the page and loses the page headers (page numbers etc.) when printed on US Letter size paper.

Fixes

Use this version.

Or (if you have texinfo 4.2) recreate the doc/gforth.ps file with

make doc DVI2PS="dvips -t letterSize -Z"

Does not build with gcc-3.3

Symptom

Gforth crashes when it is first called during the build process:
./gforth --die-on-signal -m 4M -p ".:~+:." -i kernl32l.fi -e 3 exboot.fs -e 'fpath= .|~+|.' -e 's" mach16b.fs"' ./kernel/main.fs -e "save-cross kernl16b.fi- /usr/local/bin/gforth-0.6.1 bye"
make: *** [kernl16b.fi-] Segmentation fault

Workarounds

Use an older gcc (recommended: gcc-2.95; with --enable-force-reg this is about 2-5 times faster on a Pentium4 than the workaround below.

Alternatively, use the following configure call when building Gforth:

configure CC="gcc -fno-reorder-blocks -fno-inline" --enable-force-reg

Explanation

Gforth-0.6.1 assumes that the primitives are in the machine code in the same order as in the source code, but this assumption is not true for gcc-3.3.

Known Problems when installing Gforth 0.6.0

Big-endian machines

Symptom

During building Gforth, the following error is reported:
in file included from *the terminal*:0
in file included from ../gforth-0.6.0/kernel/main.fs:92
in file included from ../gforth-0.6.0/kernel/kernel.fs:24
../gforth-0.6.0/kernel/int.fs:733: CROSS: forward 
        ['] cr catch if
            ^^
...

Workaround

Continue building with
make FORTHB='$(BUILDFORTH) -e 3 exboot.fs -e "128 allocate 2drop" -e "fpath= .|~+|$(srcdir)"'
If another instance of the same problem occurs, switch back to normal make, or try varying the 128 above.

Known Problems when installing Gforth 0.5.0

Redhat Linux 7, 7.1 for Intel

Symptom

Building Gforth hangs when using the gforth binary for the first time.

Fix

Configure with
CC="gcc -fno-gcse" ./configure --enable-force-reg --enable-indirect-threaded
This has been tested and works on gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81).

Alternatively, use the binary package. Alternatively, use kgcc (in the compat-egcs package on Redhat 7.1) to compile gforth (configure with CC=kgcc configure). Using gcc-2.95.3 (compiled from the source) is also known to work.

Explanation

A trick used in Gforth no longer works under all conditions. If you want details:

We used a trick in implementing non-primitives in direct threaded code (in particular constants); this trick pushes (through CALL) and pops a value on the stack, and the compiler, being unaware of this, must not use esp between these two instructions; this worked up to gcc-2.95, either because the compiler allocated registers well enough that it did not need the stack there, or because it did not schedule its spill code up across asm statements. In gcc-3.0.4, however (and presumably starting at gcc-2.96), these assumptions do not hold in general, and Gforth breaks.

gcc-3.0.x for Intel

Sympton

Building Gforth hangs at one step that uses the Gforth binary.

Fix

Configure with
./configure --enable-force-reg
and/or use another gcc version (gcc-2.95 recommended)

Explanation

Apparently wrong code is generated without --enable-force-reg (not totally investigated).

MacOS X, Darwin

There are a few hurdles when building Gforth on MacOS X. David N. Williams has taken them and written some instructions and support files for doing it (try several times if you have trouble following the link).

Alternatively, Jorge Acereda Maciá has produced a Gforth package for the Fink project.

Known Problems when installing Gforth 0.4.0

RedHat Linux (4.1, 4.2) for Intel

Symptom

One of the steps in building Gforth (the one involving gforthmi) fails.

Fix

Get the binary package. Or use -O0 when building engine-ditc.o. Or install gcc from the sources (from a GNU mirror, not the source RPM).

Explanation

This is apparently due to a broken installation of gcc-2.7.2.1. After installing gcc-2.7.2.1 from the sources I could install Gforth without problems.

Known Problems when installing Gforth 0.3.0

There are also a number of known bugs, but in contrast to installation problems they bite only few people, so we don't list them for now. Maybe we'll use a Debian-like bug-tracking system one day, where such things are done automagically.

Solaris

Symptom

You get a compile error about FIONREAD being undeclared.

Fix

Include sys/filio.h after sys/file.h in io.c.

RedHat Linux for Intel

Symptom

One of the steps in building Gforth (the one involving gforth-makeimage) hangs.

Fix

Get the binary package. Or install gcc from the sources (from a GNU mirror, not the source RPM). Or use -O0 when building engine-ditc.o.

Explanation

This is apparently due to a broken installation of gcc-2.7.2.1. After installing gcc-2.7.2.1 from the sources I could install Gforth without problems.

Floating-Point I/O

Various Systems that are supposed to have IEEE arithmetic

Symptoms

"-0e" is converted incorrectly; -0., infinities or NaNs are output incorrectly. A typical correct output is:
-0e f. -0.  ok
1e 0e f/ f. inf ok
1e -0e f/ f. -in ok
0e 0e f/ f. nan ok

Fix

When building Gforth, link with glibc 2.1.2 or later (the relevant functions are strtod for input and ecvt for output).

Explanation

Many C libraries contain implementations of strtod and ecvt that are not up to par with all the subtleties of IEEE FP numbers.