Due to numerous question about mips/mipsel linux,
I decided to try to generate snapshot for those systems. It finally worked (with OPT=-O- option added)

You can test them at:
ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/mipsel-linux/ or
ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/mips-linux/

Please give feedback,

Pierre Muller

I'm at a dead halt at the moment. Something blew two of my development systems yesterday, one of them being the one I use for Qemu etc. which was also the one I needed to build a kernel for a "real" MIPS system. So it's going to be days before I can test anything.

oh, very nice! big thx!

i would testing this, but please can you add a little (or more detail) description how to use this snapshot? i see some intrestet files but i cant to bring together...

greez & thx,
sky...

This is just a compressed installation:
if you expand everything into directory
/your/base/dir
then
adding /your/base/dir/bin to PATH environment variable should allow you to use this installation.

However, there are indeed at least two known problems:
1) The missing symbolic link between
bin/ppcCPU to ../lib/fpc/$FPCVERSION/ppcCPU
where CPU is etiher mips or mpisel in our case.

I don't know if this is just a limitation of tar
or something that could easily be added...

2) A basic fpc.cfg file that gets read by the ppcCPU binary to find the installed ppu and object files.

I have a .fpc.cfg file in my HOME directory which contains -Fu/home/pierre/pas/fpc-$fpcversion/lib/fpc/$fpcversion/units/$fpctarget/*

This is enough to find all installed ppu and object files as long as you install all your different Free Pascal versions into $HOME/fpc-$fpcversion
$fpcversion is simply the output of a 'ppcCPU -iV' call.

If you want to know where you could put a configuration file (if you prefer to have a different for each version for example) a good way is to use 'ppcCPU -va'
which will output a lot of information,
but look for lines containing "Configfile"

After those simple operations,
you should be able to recompile the whole
trunk SVN checkout!

Hope this helps,

Pierre Muller

I'm just about moving again here, but with a decided limp: the system that blew was 2.8GHz and all my guest OSes are now plugged into a 1GHz box. I still find being able to use a significant number of different guests in sleds/caddies useful... Unfortunately I've still not got any real MIPS hardware running here, so I'm still stuck on Qemu.

The good news is that I can still run/build trunk for mipsel on Debian "Squeeze" on Qemu without unanticipated issues (i.e. nobody reading this should assume that Lazarus will work yet).

The not-so-good news is that I built from trunk earlier but after having bus errors in Qemu's implementation of big-endian MIPS I'm now looking at the file above. Unfortunately I still get bus errors and I think the binaries have been stripped.

If I revert to a binary that I cross-built from trunk earlier, I get this:

217 1> gdb /usr/local/lib/fpc/2.7.1/ppcmips
GNU gdb (GDB) 7.0.1-debian
..
Reading symbols from /usr/local/lib/fpc/2.7.1/ppcmips...done. (gdb) run
Starting program: /usr/local/lib/fpc/2.7.1/ppcmips

Program received signal SIGBUS, Bus error.
0x0043ba68 in SYSUTILS_$$_DATETIMETOFILEDATE$TDATETIME$$LONGINT () (gdb) bt
#0 0x0043ba68 in SYSUTILS_$$_DATETIMETOFILEDATE$TDATETIME$$LONGINT () #1 0x0043edb4 in SYSUTILS_$$_UNIXTOWINAGE$LONGINT$$LONGINT () #2 0x0043fc88 in
SYSUTILS_$$_FINDGETFILEINFO$ANSISTRING$TSEARCHREC$$BOOLEAN () #3 0x0043ffe0 in SYSUTILS_$$_FINDNEXT$TSEARCHREC$$LONGINT () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb)

This is very strange:
I just installed the snapshot onto the big-endian mips machine that I use to generate the snapshot.
This machine is the one that does generate daily testsuite results for mips-linux.

I just tested a compiler cycle (with DEBUG=1) starting from this snapshot binary, and it seems to be able to generate a vanilla trunk ppcmips:
ppcmips -iDW
2012/11/21 2.7.1-r1:23032

Is this a Qemu problem?

Pierre

colleagues]

_______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Dear Mark,

于 2012/11/21 1:38, Mark Morgan Lloyd 写道:

If you want we can donate some MIPS machines to you. We have some netbooks with 800MHz Loongson2F (little endian mips, almost mips64 compatible, running debian linux/mips) in the stock.

Regards

But I see no other problems, except those that could be caused by slowness of the emulated environment (flush process timing out, which appears to be a known issue). I suggest you compile a null program and "Hello, World!" and upload them.

This is one of the reasons that I'm trying to get at least one genuine SGI system running, I don't entirely trust Qemu as a reference platform. However booting Linux on the Origin 200 looks "challenging", one Octane has a blown PSU and the other trips the RCD (suspect filter).

I'm always reluctant to accept offers like that since I'm a very long way down the pecking order and don't want to promise a level of assistance that I might not be able to deliver. On the other hand since I've got Debian running on multiple platforms here that in itself might be of some value to you... let's take this off-list.

Got bounced as spam, resent via a conferencing service we use (cix.co.uk).

Also bounced.

Recompiling trunk mipsel natively eventually failed:

/usr/bin/diff ppc3 ppcmipsel
Binary files ppc3 and ppcmipsel differ
make[2]: *** [cycle] Error 2

I think what I need to do is revert to the last version I've seen a full build working on, I've got the sources but not the svn metadata so I can't for the moment say what revision this is.

Is there a rough way of querying svn to determine what revisions were committed on a particular date?

For the record, Qemu describes its mipsel emulation as

system type : MIPS Malta
processor : 0
cpu model : MIPS 24Kc V0.0 FPU V0.0 BogoMIPS : 98.04
wait instruction : yes
microsecond timers : yes
tlb_entries : 16
extra interrupt vector : yes
hardware watchpoint : yes, count: 1, address/irw mask: [0x0ff8] ASEs implemented :
shadow register sets : 1
core : 0
VCED exceptions : not available
VCEI exceptions : not available

On Wed, November 21, 2012 12:47, Mark Morgan Lloyd wrote: .
.

Recompiling trunk mipsel natively eventually failed:

.
.

Is there a rough way of querying svn to determine what revisions were committed on a particular date?

.
.

SVN logs (e.g. http://svn.freepascal.org/svn/logs/fpc-trunk.log if talking about trunk)? As far as I understand SVN help correctly, querying the revision for a specific date should be possible using 'svn -r {date} log', but I haven't used it myself since I find working with the log files kept in our SVN tree much more convenient.

Tomas

# fpc -iDW
2012/10/17 2.7.1
# svn -r '{2012-10-17}' log http://svn.freepascal.org/svn/fpc/trunk ------------------------------------------------------------------------ r22678 | pierre | 2012-10-16 22:45:41 +0000 (Tue, 16 Oct 2012) | 1 line ..

I'll get back onto this later, I've got some Debian bugs to report :-/

But at the same time I note Pierre's

ppcmips -iDW 2012/11/21 2.7.1-r1:23032

Is there some reliable way of getting the SVN revision into the FPC version number or build date, or even into a macro or symbol so that a program can log what revision it was compiled by?

Mark Morgan Lloyd wrote

Is there some reliable way of getting the SVN revision into the FPC version number or build date, or even into a macro or symbol so that a program can log what revision it was compiled by?

Execute once: touch compiler/revision.inc

Afterwards, every time you build the compiler it will include the svn revision number in the extended version info.

Jonas

I'm happy to try helping :-) My colleagues and I have a policy of trying to do our bit to keep non-x86 systems viable because of their relative resistance to malware etc., so quite a lot of my (nominally) work time is spread out over various open-source projects. But neither I nor the company has much ready cash, which I why I often end up running on older kit which can be very
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

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

The previous version that I compiled is around r22655 and builds OK on mipsel implemented by Qemu. I'm trying it for mips (big-endian)... I might be some time.

Mark Morgan Lloyd wrote

The previous version that I compiled is around r22655 and builds OK on mipsel implemented by Qemu. I'm trying it for mips (big-endian)... I might be some time.

Definite problem on a big-endian target: fpc -i is OK but fpc -h fails with

Reading symbols from /usr/local/bin/ppcmips...done. (gdb) set arg -h
(gdb) run
Starting program: /usr/local/bin/ppcmips -h

Program received signal SIGBUS, Bus error.
0x0043eb88 in SYSUTILS_$$_UNIXTOWINAGE$LONGINT$$LONGINT () (gdb) bt
#0 0x0043eb88 in SYSUTILS_$$_UNIXTOWINAGE$LONGINT$$LONGINT () #1 0x0043fa6c in
SYSUTILS_$$_FINDGETFILEINFO$ANSISTRING$TSEARCHREC$$BOOLEAN () #2 0x0043fdc4 in SYSUTILS_$$_FINDNEXT$TSEARCHREC$$LONGINT () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb)

Same failure running fpc -l or trying to compile a trivial program. Ditto fpc -l- test.pas, or running with no options/parameters other than what are in the standard fpc.cfg.

Hi Mark,

do you use my patch for mips to
handle stack?
Without it, the backtrace doesn't work...

The bad thing is that I submitted it to gdb-patches, but it was refused, I was told that $fp should be equal to $sp according to ABI...

If you use a stock GDB, try to unpack a recent
GDB source tree, apply the one line patch below,
and recompile GDB.

Can you tell us if the backtrace looks better after this?

Pierre Muller

2012-06-11 Pierre Muller

* mips-tdep.c (mpis32_scan_prologue): Fix value of frame_offset for ADDIU $s8,$sp,FrameSize.

Index: src/gdb/mips-tdep.c
=================================================================== RCS file: /cvs/src/src/gdb/mips-tdep.c,v
retrieving revision 1.556
diff -u -p -r1.556 mips-tdep.c
--- src/gdb/mips-tdep.c 6 Jun 2012 21:34:12 -0000 1.556 +++ src/gdb/mips-tdep.c 10 Jun 2012 23:43:44 -0000 @@ -3226,6 +3226,7 @@ restart:

                (this_frame, gdbarch_num_regs (gdbarch) + 30);

              alloca_adjust = (unsigned) (frame_addr - (sp + low_word));

+ frame_offset -= low_word;
if (alloca_adjust > 0)
{
/* FP > SP + frame_size. This may be because of

colleagues]

_______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Thanks Pierre, I'll work on it between other things.

I think I got that patch into the sources from Debian, although it had moved somewhat: I I read things correctly it went into the first of two similar blocks.

Running the program using the modified GDB, I get the same as before:

0 1> which gdb
/usr/local/bin/gdb
0 1> gdb /usr/local/bin/ppcmips
GNU gdb (GDB) 7.0.1-debian
..
(gdb) set arg -h
(gdb) run
Starting program: /usr/local/bin/ppcmips -h

Program received signal SIGBUS, Bus error.
0x0043eb88 in SYSUTILS_$$_UNIXTOWINAGE$LONGINT$$LONGINT () (gdb) bt
#0 0x0043eb88 in SYSUTILS_$$_UNIXTOWINAGE$LONGINT$$LONGINT () #1 0x0043fa6c in
SYSUTILS_$$_FINDGETFILEINFO$ANSISTRING$TSEARCHREC$$BOOLEAN () #2 0x0043fdc4 in SYSUTILS_$$_FINDNEXT$TSEARCHREC$$LONGINT () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb)

A curious thing is that when I first ran it from the build directory without "make install" I appeared to get more info:

Program received signal SIGBUS, Bus error.
0x0043eb88 in SYSUTILS_$$_UNIXTOWINAGE$LONGINT$$LONGINT () (gdb) bt
#0 0x0043eb88 in SYSUTILS_$$_UNIXTOWINAGE$LONGINT$$LONGINT () #1 0x0043fa6c in
SYSUTILS_$$_FINDGETFILEINFO$ANSISTRING$TSEARCHREC$$BOOLEAN () #2 0x0043fdc4 in SYSUTILS_$$_FINDNEXT$TSEARCHREC$$LONGINT () #3 0x00440074 in
SYSUTILS_$$_FINDFIRST$ANSISTRING$LONGINT$TSEARCHREC$$LONGINT () During symbol reading, couldn't parse type; debugger out of date?. #4 0x00453428 in TCACHEDDIRECTORY__RELOAD (this=<error reading variable>) at cfileutl.pas:277
#5 0x00453050 in TCACHEDDIRECTORY__FORCEUSECACHE (this=<error reading variable>) at cfileutl.pas:234
#6 0x00452fd8 in TCACHEDDIRECTORY__TRYUSECACHE (this=<error reading variable>) at cfileutl.pas:223
#7 0x00453ad8 in TCACHEDDIRECTORY__DIRECTORYEXISTS (ANAME=0x2aaa880c 'mipseb-linux',
this=<error reading variable>) at cfileutl.pas:357 #8 0x00454244 in TDIRECTORYCACHE__DIRECTORYEXISTS ( ANAME=0x2aac822c '/usr/local/lib/fpc/2.7.1/units/mipseb-linux', this=<error reading variable>)
at cfileutl.pas:433
#9 0x004555b8 in PATHEXISTS (F=0x2aac826c
'/usr/local/lib/fpc/2.7.1/units/mipseb-linux/', ALLOWCACHE=true) at cfileutl.pas:687
#10 0x00457e40 in TSEARCHPATHLIST__ADDPATH (SRCPATH=0x0, S=0x0, ADDFIRST=true,
this=<error reading variable>) at cfileutl.pas:1131 #11 0x00456b88 in TSEARCHPATHLIST__ADDPATH (S=0x2aac816c '/usr/local/lib/fpc/2.7.1/units/mipseb-linux',
ADDFIRST=true, this=<error reading variable>) at cfileutl.pas:986 #12 0x0063bf64 in TOPTION__INTERPRET_OPTION (
OPT=0x2aab910c
'-Fu/usr/local/lib/fpc/$fpcversion/units/$fpctarget', ISPARA=false, this=<error reading variable>) at options.pas:1146 #13 0x00641724 in TOPTION__INTERPRET_FILE (FILENAME=0x2aaa87ac '/etc/fpc.cfg',
this=<error reading variable>) at options.pas:2237 #14 0x00644358 in READ_ARGUMENTS (CMD=0x0) at options.pas:2932 #15 0x00427f90 in INITCOMPILER (CMD=0x0) at compiler.pas:190 #16 0x004280c0 in COMPILE (CMD=0x0) at compiler.pas:237 #17 0x0040043c in main () at pp.pas:233
(gdb) quit

However I don't entirely trust this since there could be some unholy mix of modified and unmodified libraries.

This was caused by insufficient alignment of Double-typed temp variables, fixed in r23146. Moreover, it appeared that function UnixToWinAge wasn't doing anything useful since year 2005, so it was removed in r23145, making FindFirst/FindNext routines somewhat faster (and able to run without FPU).

Now I am able to run the big-endian MIPS compiler on QEMU. Hoping you'll be able to reproduce it, too.

Regards,
Sergei

I'll see what I can do, but I've not got any real hardware running here which is causing me problems (Qemu performance isn't brilliant).

Hi Sergei and Mark,
16.12.2012 12:41, Sergei Gorelkin:
[...]

This is to remind you guys that if you wish to do some testing/debugging/etc on a real mips device via ssh, two debian mips boxes (big and little endian) with plenty of disk space are running here 24/7 for exactly that purpose. They are not much loaded and I can create some account(s) for you any time.

Nikolai

The FPC team has a MIPS device (longsoon?) available. It's currently switched off, but can be switched on at any time.

Michael.

17.12.2012 19:12,
[...]

The FPC team has a MIPS device (longsoon?) available. It's currently switched off, but can be switched on at any time.

Ah, ok. That's good news. If it is longsoon then it must be much faster than mine. (Though IIRC it only exists in little endian variant). Anyway, I'll still keep my boxes up for now.

Nikolai

Thanks Nikolai, noted with thanks. However at the moment- for reasons related to other things I've got on the boil- I'm trying to limit myself to machines that I've actually got in my "museum". I've got SGI although only running IRIX at the moment, little-endian hardware remains a problem and in practical terms I'm not sure I can put very much more effort into it.

Basic operation OK. There's a slight problem in that the build produces a directory /usr/local/lib/fpc/2.7.1/units/mips-linux while ppcmips running with the standard fpc.cfg expects .../mipseb-linux

Full build works with a standard set of parameters. Albeit slowly. Only peculiarity was that I had to copy the fpc binary manually before I could run sudo make install

I'll try to run the test suite for both mipsel and mips(eb), but a higher priority has to be getting one of my SGI machines running.

Will this work on other OS running on MIPS? How much work would it be to get it going on OpenBSD for example?

get

it going on OpenBSD for example?

It shouldn't be much work...
just look at the content of openbsd/CPU/ directories, you will see what needs to be implemented specifically... Starting with the linux equivalent code should work for most include files, the startup prt0.as file might be a little bit more problematic...

Pierre

Thanks, I'll wait until Mark/Fuxin get it running 100% on Linux and then maybe have a look at it.