[fpc-devel] FPC on SPARC using both Linux and Solaris

[Mark Morgan Lloyd]

This time of year tends to be fairly quiet for us, and I've been using some of 
the slack to continue tinkering with FPC on SPARC- with, I must say, mixed 
success. Because I know that Jonas tests it on Solaris I've fired up an extra 
machine here, but at present I don't really have enough hardware to do v10 
justice- I'm hoping to be able to change that, but I need to be able to 
demonstrate some progress here first.

Apologies for a fairly long posting and if some of it is a bit disjointed, but 
it's cut-and-pasted from my noted of the last few weeks. To get the ball 
rolling here's an executive summary:

* 2.0.0 appears OK on sparc-linux.

* 2.0.2 is broken in some way on sparc-linux: won't compile.

* 2.0.4 fails tmt1 on sparc-linux, something wrong in pthreads.

* 2.1.4 has known code-generation problems and fails tmt1 on sparc-linux.

* Lazarus appears to compile using 2.1.4 on sparc-linux but doesn't run reliably.

* 2.1.1 appears OK on sparc-solaris.

* 2.1.1 on sparc-solaris has problems building 2.0.4 and 2.1.4.

* 2.1.1 on sparc-solaris will not compile Lazarus.

* 2.1.1 on sparc-solaris compiles a working tmt1.

My tentative conclusion is that on sparc-solaris the problems are almost 
certainly that I've not worked out how to do things, but on sparc-linux some 
sort of code-generation problem has crept in possibly as early as 2.0.2.

We really do want to get FPC working with SPARC here, and I'm very much open 
to suggestions as to how to progress things. My own feeling is that a useful 
way to move forward would be to find what I'm doing wrong with the Solaris 
compilation, possibly get Lazarus working with it, and then to revert to Linux.

If anybody's still reading, detail follows.
-------------------------------------------

Linux
-----

Starting off with the binary of FPC 2.0.0 available for Linux/SPARC which 
installs and runs without problem.

The 2.0.0 compiler builds the 2.0.0 sources and completes the self-tests. I'm
not saying that everything runs 100% successfully- it would need somebody more
familiar with the system to judge that- but it doesn't crash or lock up. I do
note some interaction with the current session's date/time which sometimes
screws the desktop or X server- I presume this is a side-effect of one of the 
tests.

The 2.0.0 compiler as distributed fails to build the 2.0.2 sources. The first
time ppc2 is run in anger it results in:

-----8<-----
make[7]: Entering directory `/usr/local/src/fpc/fpc/rtl/linux'
as -o /usr/local/src/fpc/fpc/rtl/units/sparc-linux/prt0.o sparc/prt0.as
as -o /usr/local/src/fpc/fpc/rtl/units/sparc-linux/dllprt0.o sparc/dllprt0.as
as -o /usr/local/src/fpc/fpc/rtl/units/sparc-linux/cprt0.o sparc/cprt0.as
as -o /usr/local/src/fpc/fpc/rtl/units/sparc-linux/gprt0.o sparc/gprt0.as
/usr/local/src/fpc/fpc/compiler/ppc2 -Ur -Ur -Xs  -n -Fi../inc -Fi../sparc
-Fi../unix -Fisparc -FE. -FU/usr/local/src
/fpc/fpc/rtl/units/sparc-linux -dsparc -dRELEASE -Us -Sg system.pp
sparc.inc(60,3)  msg nr 1018
An unhandled exception occurred at $0002C84C :
EInvalidPointer : Invalid pointer operation
   $0002C84C
   $0007217C
   $0004A4C0
   $000407DC
   $000103B0
An unhandled exception occurred at $00000030 :
An unhandled exception occurred at $000FF00B :
An unhandled exception occurred at $000FF003 :
An unhandled exception occurred at $000FF003 :
..
----->8-----

with the final message repeating until the session is killed. This is
approximately reproducible if executed by hand, there is no obvious error in
the indicated source.

The 2.0.0 compiler as distributed compiles 2.0.4. 2.0.4 tests DO NOT run to
completion, the failing test is tmt1 which locks up:

-----8<-----
utils/dotest 
-c/usr/local/src/fpc/fpcbuild_2.0.4_exp/fpcsrc/tests/../compiler/ppcsparc -e 
test/tmmx1.pp
Abort: Compiler cpu "sparc" is not in list "i386"
utils/dotest 
-c/usr/local/src/fpc/fpcbuild_2.0.4_exp/fpcsrc/tests/../compiler/ppcsparc -e 
test/tmove.pp
utils/dotest 
-c/usr/local/src/fpc/fpcbuild_2.0.4_exp/fpcsrc/tests/../compiler/ppcsparc -e 
test/tmt1.pp
----->8-----

Running manually:

-----8<-----
root at pye-dev-01:/usr/local/src/fpc/fpcbuild_2.0.4_exp/fpcsrc/tests/output/sparc-linux/test# 
./tmt1
An unhandled exception occurred at $00004267 :
EAccessViolation : Access violation
   $00004267
----->8-----

Return code is 217.

2.0.4 sometimes fails to compile 2.1.4, the problem (according to Jonas) 
apparently being inconsistently-initialised register allocation (or similar) 
in the 2.1.4 compiler. If the build completes the self-test again locks up on
tmt1.

I've spent a lot of time trying to hack my way through tmt1 with gdb, things 
are going wrong somewhere in pthread_create() but beyond that I get bogged down.

After somebody on a private conferencing system I use (CIX) had a similar 
problem with pthreads I switched from Debian "Etch" to "Lenny" which uses NPTL 
rather than linuxthreads (i.e. handles threads in the kernel rather than in 
the libraries). There was no apparent change to the 2.0.4 or 2.1.4 problems. 
I've not yet had an opportunity to try a different Linux distribution (e.g. 
Splack).

Solaris
-------

Starting off with the binary of 2.1.1 available for Solaris-10/SPARC which
installs but needs the addition of GNU as (assembler) and make, and symlinks
gas -> as and gld -> ld before it will compile a Hello, World! test program. 
I've also installed GNU tar in case any problems are caused by bad 
de-archiving (doesn't appear to change anything).

I've had minimal success with Solaris-8 or with Linux 2.2 running on a
SPARCserver. If the compiler worked with either of these it would be an
interesting curiosity but as OSes go they're too old to test things on credibly.

Solaris-8: after installation of as etc. fpcmkcfg fails to run due to missing
libm.so.2. I'm assuming that's fatal and unfixable.

Linux 2.2 (Debian "Woody"): 2.0.0 installs, compiles "Hello, World!" to
apparently good code. fp doesn't run, 'GLIBC_2.3 not found'. I believe it
compiles 2.0.0 and runs tests to completion but I'm not treating this system
as particularly credible: the FPC compiler doesn't make efficient use of the
multiple processors making the system too slow, noisy and hot to be worth while.

I've got a system which just about runs Solaris-10, but it's marginal and 
development is painful.

Attempting to build 2.1.4 on Solaris using the distributed 2.1.1 binary 
results in an error:

-----8<-----
make[6]: Entering directory `/usr/local/src/fpc/fpcbuild-2.1.4/fpcsrc/rtl'
make -C solaris all
make[7]: Entering directory `/usr/local/src/fpc/fpcbuild-2.1.4/fpcsrc/rtl/solaris'
/usr/local/bin/ppcsparc -Ur -dFPC_USE_LIBC -dNOMOUSE -Ur -Xs -O2 -n -Fi../inc 
-Fi../sparc -Fi../unix -Fi../solaris/sparc -FE. 
-FU/usr/local/src/fpc/fpcbuild-2.1.4/fpcsrc/rtl/units/sparc-solaris -dsparc 
-dRELEASE -Us -Sg system.pp
systemh.inc(94,15) Error: Duplicate identifier "Real"
varianth.inc(253,12) Error: Function is already declared Public/Forward 
"operator :=(const Double):Variant"
----->8-----

Trying to compile Lazarus 0.9.22 with 2.1.1 results in

-----8<-----
Compiling lazconfigstorage.pas
Assembling lazconfigstorage
lresources.pp(97,15) Error: There is no method in an ancestor class to be 
overridden: "TLRSObjectReader.Read(var <Formal type>, LongInt)"
lresources.pp(142,15) Error: There is no method in an ancestor class to be 
overridden: "TLRSObjectWriter.Write(const <Formal type>, LongInt)"
lresources.pp(385,1) Fatal: There were 2 errors compiling module, stopping
Fatal: Compilation aborted
make[1]: *** [alllclunits.ppu] Error 1
make[1]: Leaving directory `/usr/local/share/lazarus/lcl'
make: *** [lcl] Error 2
----->8-----

However on other platforms 2.1.4 has been running for some time and I suspect 
that Lazarus has gained something the slightly older compiler doesn't like.

Lazarus is documented as requiring 2.0.2 minimum. I know that I can't build 
2.0.2 on Linux i.e. the latest solid version is 2.0.0. What I haven't tried 
yet is reverting to a slightly older version e.g. 2.0.4 under Solaris using 
the 2.1.1 binary:

-----8<-----
make ./msg2inc
make[7]: Entering directory 
`/usr/local/src/fpc/fpcbuild_2.0.4_exp/fpcsrc/compiler'
/usr/local/bin/ppcsparc -Ur -Xs  -n -Fusparc -Fusystems 
-Fu/usr/local/src/fpc/fpcbuild_2.0.4_exp/fpcsrc/rtl -Fisparc -FE. 
-FUsparc/units/sparc-solaris -dRELEASE  -dsparc -dGDB -dBROWSERLOG  -FE. 
utils/msg2inc.pp
Fatal: Can't find unit System
Fatal: Compilation aborted
make[7]: *** [msg2inc] Error 1
----->8-----

Using -vt the problem appears to be that "make all" is trying to use 
system.ppu and/or system.o from the 2.0.4 build directory structure rather 
than the ones that match the 2.1.1 compiler.

I've only had partial success trying to work around this.


However, the really good news is that 2.1.1 on Solaris compiles and runs tmt1.pp.


Which takes me back to my original conclusions:

* 2.0.0 appears OK on sparc-linux.

* 2.0.2 is broken in some way on sparc-linux.

* 2.0.4 fails tmt1 on sparc-linux.

* 2.1.4 has known code-generation problems and fails tmt1 on sparc-linux.

* Lazarus appears to compile using 2.1.4 on sparc-linux but doesn't run reliably.

* 2.1.1 appears OK on sparc-solaris.

* 2.1.1 on sparc-solaris has problems building 2.0.4 and 2.1.4.

* 2.1.1 on sparc-solaris will not compile Lazarus.

* 2.1.1 on sparc-solaris compiles a working tmt1.

My tentative conclusion is that on sparc-solaris the problems are almost 
certainly that I've not worked out how to do things, but on sparc-linux some 
sort of code-generation problem has crept in possibly as early as 2.0.2.

Any light that can be thrown on any of this would be very much appreciated.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]