I've been tinkering for a few weeks, hoping eventually to get Lazarus running on linux/sparc. I'm currently using FPC 2.1.4, apologies for not being nearer the "bleeding edge".

I've got problems with Lazarus that I suspect could be connected with code generation, because of this I've stepped back and am trying to run the FPC test suite. I can do this fine for linux/i386 (hosted on Debian "Sarge") but linux/sparc (on "Etch") grinds to an unseemly halt:

/fpcbuild-2.1.4/fpcsrc/compiler/ppcsparc -n -FEsparc-linux -Tlinux popuperr.pp make[1]: Leaving directory `/fpcbuild-2.1.4/fpcsrc/tests/units' /bin/cp -fp test/cg/obj/linux/sparc/ctest.o test/cg /bin/cp -fp test/cg/obj/linux/sparc/tcext3.o test/cg /bin/cp: cannot stat `test/cg/obj/linux/sparc/tcext3.o': No such file or directory make: *** [copyfiles] Error 1
2 3> echo TEST_FPC
0 3> echo $TEST_FPC
/fpcbuild-2.1.4/fpcsrc/compiler/ppcsparc

running this with make -d gives a bit more detail:

/fpcbuild-2.1.4/fpcsrc/compiler/ppcsparc -n -FEsparc-linux -Tlinux popuperr.pp Putting child 0x0007b118 (popuperr.ppu) PID 22199 on the chain. Live child 0x0007b118 (popuperr.ppu) PID 22199
Reaping winning child 0x0007b118 PID 22199
Removing child 0x0007b118 PID 22199 from chain.
Successfully remade target file `popuperr.ppu'.
Finished prerequisites of target file `extra'.
Must remake target `extra'.
Successfully remade target file `extra'.
Finished prerequisites of target file `all'.
Must remake target `all'.
Successfully remade target file `all'.
Finished prerequisites of target file `default'.
Must remake target `default'.
Successfully remade target file `default'.
make[1]: Leaving directory `/fpcbuild-2.1.4/fpcsrc/tests/units' Reaping winning child 0x00143468 PID 22142
Removing child 0x00143468 PID 22142 from chain.
Successfully remade target file `units'.
Considering target file `copyfiles'.
File `copyfiles' does not exist.
Pruning file `output/sparc-linux'.
Finished prerequisites of target file `copyfiles'. Must remake target `copyfiles'.
/bin/cp -fp test/cg/obj/linux/sparc/ctest.o test/cg Putting child 0x001450e8 (copyfiles) PID 22201 on the chain. Live child 0x001450e8 (copyfiles) PID 22201
Reaping winning child 0x001450e8 PID 22201
/bin/cp -fp test/cg/obj/linux/sparc/tcext3.o test/cg /bin/cp: cannot stat `test/cg/obj/linux/sparc/tcext3.o': No such file or directory Live child 0x001450e8 (copyfiles) PID 22202
Reaping losing child 0x001450e8 PID 22202
make: *** [copyfiles] Error 1
Removing child 0x001450e8 PID 22202 from chain.
2 3>

I can see that 2.1.5 is regularly being tested on Solaris so things can't be too badly broken.

I can confirm that the ...test/cg/obj/linux/sparc/ directory exists and is writable, I'm doing all of this close to / in case there are still pathlength issues anywhere.

Can anybody point me at where I should be looking?

If I can get this working and- in particular- if I can get a reliable copy of Lazarus on linux/sparc I hope to be able to continue testing releases etc., however I've got a fairly major learning curve to surmount :-/

That file is supposed to be in svn, but it isn't in fixes. You can download it (along with some others) from
http://svn.freepascal.org/svn/fpc/trunk/tests/test/cg/obj/linux/sparc/

Jonas

Drat :-) I was assuming that the file was built from source somewhere rather than being a preexisting binary... I should have looked in the sibling directories.

Incidentally, something curious here. You might remember that a week ago I was getting stuck on the inconsistent register-assignment nasty, I built and installed an apparently-working 2.1.4 shortly after you pointed out that it tended to be a transiant problem. Odd thing is that since that point I've gone through the entire exercise a second time- 2.0.0 binary compiling 2.0.4 hence compiling 2.1.4, and the 2.1.4 compilation hadn't failed.

Work continues here, I'll be back. I /really/ want to get this sorted out.

I know, it only happens intermittently (in a way that suggests an uninitialised variable or memory localtion), but have no idea what it's caused by. Valgrind doesn't find anything in an i386 to sparc cross compiler, so it's probably an error somewhere in the sparc code generator (or in a sparc rtl assembler routine)

Jonas

I'm obviously keeping an eye on this, but I'm wondering whether there's a binary (library or executable) that was installed on the system once I had a working 2.1.4, which was not overwritten when I reverted to 2.0.0 or 2.0.4 and subsequently used when I rebuilt 2.1.4. In some ways it will be a relief if it starts coming up with the same fault again :-)

Tests still running, more later.

Mark Morgan Lloyd wrote

Tests still running, more later.

OK, I think it's stuck. It's been sitting here for the last few hours:

utils/dotest -c/fpcbuild-2.1.4/fpcsrc/compiler/ppcsparc -e test/tmmx1.pp Abort: Compiler cpu "sparc" is not in list "i386"
utils/dotest -c/fpcbuild-2.1.4/fpcsrc/compiler/ppcsparc -e test/tmove.pp utils/dotest -c/fpcbuild-2.1.4/fpcsrc/compiler/ppcsparc -e test/tmt1.pp

tmt1.pp doesn't look like it should take /that/ lomg to run, even on a 450MHz system.

Noting seems to be taking an inordinate amount of CPU or memory, but I've got about 99 tmt1 processes running all started 7 hours ago... is that right?

Ah- the kernel buffer is full of "Kernel unaligned access" messages. What I can't say is whether this is the result of testing or because of something that was being done on this machine a few minutes ago, however this is suspiciously similar to the fault I was getting in Lazarus.

I'll leave the system in its current state if I can in case there's anything worth checking.

Any hints appreciated :-)

I'm really not experienced with gdb etc., a logic analyser is far more my style. However as far as I can tell the third thread bombs immediately after creation (this is an aggregate of several sessions, so I don't guarantee the addresses):

0x0004decc in
CTHREADS_CBEGINTHREAD$POINTER$LONGWORD$TTHREADFUNC$POINTER$LONGWORD$LONGINT$$LONGINT ()
(gdb)
0xf7d64640 in pthread_create@@GLIBC_2.1 () from /lib/v9/libpthread.so.0

..

0xf7d486c8 in pthread_create@@GLIBC_2.1 () from /lib/v9/libpthread.so.0 (gdb)
[New Thread 16386 (LWP 6259)]
0xf7d486cc in pthread_create@@GLIBC_2.1 () from /lib/v9/libpthread.so.0 (gdb)
0xf7d486d0 in pthread_create@@GLIBC_2.1 () from /lib/v9/libpthread.so.0 (gdb)

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16386 (LWP 6259)]
0x9de3bfa0 in ?? ()
(gdb) info threads
* 3 Thread 16386 (LWP 6259) 0x9de3bfa0 in ?? ()
2 Thread 32769 (LWP 6258) 0xf7e903b4 in poll () from /lib/v9/libc.so.6 1 Thread 16384 (LWP 6208) 0xf7d486d0 in pthread_create@@GLIBC_2.1 () from /lib/v9/libpthread.so.0

..

6207 pts/7 S+ 0:02 gdb -d ../../../test tmt1 6208 pts/7 T 0:00
/fpcbuild-2.1.4/fpcsrc/tests/output/sparc-linux/test/tmt1 6258 pts/7 T 0:00
/fpcbuild-2.1.4/fpcsrc/tests/output/sparc-linux/test/tmt1 6259 pts/7 T 0:00
/fpcbuild-2.1.4/fpcsrc/tests/output/sparc-linux/test/tmt1

For the moment I'm reading that as thread 1 (6208) is the original program, threads 1 and 2 (6208, 6258) are somewhere in kernel space and thread 3 (6259) has been started with dud state- pc, npc or something... not sure but I don't much like the look of the stack which appears to be at a similarly indeterminate address.

I need to spend time trying to get to grips with gdb etc. :-/