Hi,

Periodically I try to cross-compile a simple program [1] for my router with fpc trunk.
It starts but does nothing (does not return to command prompt).

Noticed an earlier mail from Dennis Poon where he described the same behaviour.

Any suggestions?
Thanks,
Reinier

cat /proc/cpuinfo
system type : Atheros AR9344 rev 2
machine : TP-LINK TL-WDR3600/4300/4310 processor : 0
cpu model : MIPS 74Kc V4.12
BogoMIPS : 278.93
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0000, 0x0ff8, 0x0ff8, 0x0ff8]
ASEs implemented : mips16 dsp
shadow register sets : 1
kscratch registers : 0
core : 0
VCED exceptions : not available
VCEI exceptions : not available

]1]
program hellomips;
{$mode objfpc}
// let's use short strings {.$H+}

{not$DEFINE UseCThreads} //otherwise it seems we get pthreads which gdb can't debug
uses

  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Classes
  ;

begin
  writeln('hello mips');
end.

with options
-MObjFPC -Scghi -Tlinux -Pmips -CpMIPS32R2 -Xs -vewnhibq -Filib\mips-linux -Fu. -FUlib\mips-linux -l

relevant fpc.cfg snippet
# begin fpcup do not remove mips-linux
#cross compile settings dependent on both target OS and target CPU #IFDEF CPUMIPS
#IFDEF LINUX
# Inserted by fpcup 06/09/2014 11:05:24
-CpMIPS32R2
-CfSOFT
-FDC:\development\cross\bin\mips-linux\
-XPmips-linux-
-Tlinux
-FlC:\development\cross\lib\mips-linux\
-Xr/usr/lib
-FL/usr/lib/ld-linux.so.2
#ENDIF
#ENDIF
# end fpcup do not remove

Hi,

Periodically I try to cross-compile a simple program [1] for my router with fpc trunk.
It starts but does nothing (does not return to command prompt).

Noticed an earlier mail from Dennis Poon where he described the same behaviour.

Any suggestions?
Thanks,
Reinier

cat /proc/cpuinfo
system type : Atheros AR9344 rev 2
machine : TP-LINK TL-WDR3600/4300/4310 processor : 0
cpu model : MIPS 74Kc V4.12
BogoMIPS : 278.93
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0000, 0x0ff8, 0x0ff8, 0x0ff8]
ASEs implemented : mips16 dsp
shadow register sets : 1
kscratch registers : 0
core : 0
VCED exceptions : not available
VCEI exceptions : not available

]1]
program hellomips;
{$mode objfpc}
// let's use short strings {.$H+}

{not$DEFINE UseCThreads} //otherwise it seems we get pthreads which gdb can't debug
uses

  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Classes
  ;

begin
  writeln('hello mips');
end.

with options
-MObjFPC -Scghi -Tlinux -Pmips -CpMIPS32R2 -Xs -vewnhibq -Filib\mips-linux -Fu. -FUlib\mips-linux -l

relevant fpc.cfg snippet
# begin fpcup do not remove mips-linux
#cross compile settings dependent on both target OS and target CPU #IFDEF CPUMIPS
#IFDEF LINUX
# Inserted by fpcup 06/09/2014 11:05:24
-CpMIPS32R2
-CfSOFT
-FDC:\development\cross\bin\mips-linux\
-XPmips-linux-
-Tlinux
-FlC:\development\cross\lib\mips-linux\
-Xr/usr/lib
-FL/usr/lib/ld-linux.so.2
#ENDIF
#ENDIF
# end fpcup do not remove

I think the previous discussion wound down with the consensus that the distro had custom libraries, possibly derived from ulibc, and that the compiler etc. would have to be specially built for those. I was hoping to set a Qemu-based system to investigate, but didn't get anywhere due to other commitments.

Ok. It's running openwrt (also so that may well be the case; however I copied over [1] the libs [2] from the device to my desktop, so that should be a step in the right direction.... but presumably I need to match the cross binutils [3] ld with the uclibc ld one?!?

Also tested with fpc at
ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/mips-linux/ which (perhaps unsurprisingly given the above) shows the same problem.

[1] from my notes
openwrt router mips (big endian) uclibc libuClibc-0.9.33.2 copied
/lib
/usr/lib
(only the root dirs)

[2]
crtbegin.o
crtbeginS.o
crtbeginT.o
crtend.o
crtendS.o
crtfastmath.o
ld-uClibc.so.0
ld-uClibc-0.9.33.2.so
libblkid.so.1
libblkid.so.1.1.0
libblobmsg_json.so
libc.so.0
libcrypt.so.0
libcrypt-0.9.33.2.so
libcrypto.so.1.0.0
libcurses.so
libdl.so.0
libdl-0.9.33.2.so
libelf.so.0
libelf.so.0.8.13
libform.so
libform.so.5
libform.so.5.7
libfreeswitch.so.1
libfreeswitch.so.1.0.0
libgcc.a
libgcc_eh.a
libgcc_s.so.1
libgcov.a
libhistory.so
libhistory.so.5
libhistory.so.5.2
libip4tc.so
libip4tc.so.0
libip4tc.so.0.0.0
libiwinfo.so
libjpeg.so.62
libjpeg.so.62.0.0
libjson.so.0
libjson.so.0.0.1
liblua.so.5.1.4
liblzo2.so
liblzo2.so.2
liblzo2.so.2.0.0
libm.so.0
libm-0.9.33.2.so
libmenu.so
libmenu.so.5
libmenu.so.5.7
libncurses.so
libncurses.so.5
libncurses.so.5.7
libnl-tiny.so
libpanel.so
libpanel.so.5
libpanel.so.5.7
libpcap.so
libpcap.so.1.1
libpcap.so.1.1.1
libpng.so.3
libpng.so.3.46.0
libpng12.so.0
libpng12.so.0.46.0
libpq.so.5
libpq.so.5.3
libpthread.so.0
libpthread-0.9.33.2.so
libreadline.so
libreadline.so.5
libreadline.so.5.2
librt.so.0
librt-0.9.33.2.so
libsqlite.so.0
libsqlite.so.0.8.6
libsqlite3.so.0
libsqlite3.so.0.8.6
libssl.so.1.0.0
libstdc++.so.6
libstdc++.so.6.0.16
libubox.so
libubus.so
libuci.so
libuClibc-0.9.33.2.so
libusb.so
libusb-0.1.so.4
libusb-0.1.so.4.4.4
libutil.so.0
libutil-0.9.33.2.so
libuuid.so.1
libuuid.so.1.3.0
libxtables.so
libxtables.so.5
libxtables.so.5.0.0
libz.so
libz.so.1
libz.so.1.2.7

[3]
mips-linux-ar.exe
mips-linux-as.exe
mips-linux-ld.exe
mips-linux-nm.exe
mips-linux-objcopy.exe
mips-linux-objdump.exe
mips-linux-strip.exe

06.09.2014 14:53, Reinier Olislagers пишет:

The reason could be that uclinux kernel passes argc,argv and envp on startup different to regular linux, which is not yet supported for mips targets.

Regards,
Sergei

Arggghhh. Ok, thanks, Sergei!

Hi!

06.09.2014 14:53, Reinier Olislagers:
[...]

Ok. It's running openwrt (also so that may well be the case; however I

Prebuilt/preflashed openwrt images most definitely do not have normal glibc, which is supposedly expected by normal linux rtl. Although I haven't checked myself, I think you could either try to somehow remove glibc dependancy for your test, or rebuild (and reflash) openwrt yourself with glibc/eglibc enabled, which might in turn require some digging and patching, see e.g.
https://forum.openwrt.org/viewtopic.php?id=31174

On the other hand, if you are going to do some fpc-related testing/development/etc on mips, I can create and account for you on one of my debian mips boxes for remote access (Those are only used for daily builds so are idle most time of day).

Nikolai

This might be completely unhelpful, but I'll post it anyway just in case it's perversely relevant.

I had FPC running on SPARC under Solaris 10, and investigated getting it running on Solaris 8. The problem turned out to be that a system library (let's say it was libc.so, but I'm working from memory) was symlinked to libc.so.2 on Solaris 10 but libc.so.1 on Solaris 8, and the linking stage was resolving the symlink rather than leaving it until the program was run.

In the end I did something like copying libc.so.2 to libc.so.1 and changing libc.so to point to the latter. I built FPC (possibly just ppcsparc) and copied that to the v8 system, then restored the original symlink. At that point FPC ran OK on v8.

Thanks. I'll have a look...

On the other hand, if you are going to do some fpc-related testing/development/etc on mips, I can create and account for you on one of my debian mips boxes for remote access (Those are only used for daily builds so are idle most time of day).

Thanks for your kind offer, but apart from some DBF related stuff I doubt I'll be going to do some FPC-related development on the box. When circumstances change, I'll get in touch ;)

Am 06.09.2014 11:27 schrieb "Reinier Olislagers" <

Would you please as a test remove the Classes unit as well? It does some rather heavyweight initialization (which I noticed during getting m68k back to life).

with options -MObjFPC -Scghi -Tlinux -Pmips -CpMIPS32R2 -Xs -vewnhibq -Filib\mips-linux -Fu. -FUlib\mips-linux -l

Are you sure "mips" is the big endian version? (I don't remember whether it's mips and mipsle or mipsbe and nips...)

Additionally a simple Helloworld binary like that should not have any library dependencies (FPC's RTL normally uses syscalls directly on Linux after all). Would you please check with the mips objdump whether this is really the case?

Regards,
Sven

Done. No change unfortunately.
FPC r28606

Are you sure "mips" is the big endian version? (I don't remember whether it's mips and mipsle or mipsbe and nips...)

Yep. It's mips and mipsel.

Additionally a simple Helloworld binary like that should not have any library dependencies (FPC's RTL normally uses syscalls directly on Linux after all).

Ok, thanks, that helps.

Would you please check with the mips objdump whether this is really the case?

Should this do it?
objdump -x "hellomips" | grep -i c

If so, apparently no mention of a c library:
architecture: mips:isa32r2, flags 0x00000102:
EXEC_P, D_PAGED
STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2 Sections:
CONTENTS, ALLOC, LOAD, READONLY, DATA, LINK_ONCE_SAME_SIZE CONTENTS, ALLOC, LOAD, READONLY, CODE
CONTENTS, ALLOC, LOAD, READONLY, DATA
CONTENTS, ALLOC, LOAD, DATA
CONTENTS, ALLOC, LOAD, DATA
ALLOC
ALLOC
CONTENTS, READONLY

Generated executable at
https://bitbucket.org/reiniero/fpc_laz_patch_playground/downloads/hellomips

objdump -x "hellomips" > hellomips_objdump.txt
output in
https://bitbucket.org/reiniero/fpc_laz_patch_playground/downloads/hellomips_objdump.txt

Reinier Olislagers wrote

On 06/09/2014 22:38, Sven Barth wrote: objdump -x "hellomips" > hellomips_objdump.txt

The output is not that big so repeated below

hellomips: file format elf32-tradbigmips
hellomips
architecture: mips:isa32r2, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x004000e0

Program Header:
0x70000000 off 0x000000b4 vaddr 0x004000b4 paddr 0x004000b4 align 2**2 filesz 0x00000018 memsz 0x00000018 flags r--
LOAD off 0x00000000 vaddr 0x00400000 paddr 0x00400000 align 2**16 filesz 0x000405f8 memsz 0x000405f8 flags r-x
LOAD off 0x00040600 vaddr 0x00450600 paddr 0x00450600 align 2**16 filesz 0x00005500 memsz 0x000076b0 flags rw-
STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2 filesz 0x00000000 memsz 0x00000000 flags rw-
private flags = 70001001: [abi=O32] [mips32r2] [not 32bitmode] [noreorder]

Sections:
Idx Name Size VMA LMA File off Algn 0 .reginfo 00000018 004000b4 004000b4 000000b4 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA, LINK_ONCE_SAME_SIZE 1 .text 00040184 004000d0 004000d0 000000d0 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .rodata 000003a0 00440258 00440258 00040258 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .data 00005428 00450600 00450600 00040600 2**4 CONTENTS, ALLOC, LOAD, DATA
4 .got 000000d0 00455a30 00455a30 00045a30 2**4 CONTENTS, ALLOC, LOAD, DATA
5 .sbss 00000014 00455b00 00455b00 00045b00 2**2 ALLOC
6 .bss 00002190 00455b20 00455b20 00045b00 2**4 ALLOC
7 .pdr 00009980 00000000 00000000 00045b00 2**2 CONTENTS, READONLY
SYMBOL TABLE:
no symbols

Am 07.09.2014 11:25 schrieb "Reinier Olislagers" <

Well... Was worth a try....

> Are you sure "mips" is the big endian version? (I don't remember whether > it's mips and mipsle or mipsbe and nips...) Yep. It's mips and mipsel.

Noted ^^

Indeed.

We have at least two testsuite runs on BigEndian that only have an overviewable amount of errors, so this indeed seems like something specific to the system or the way you compiled it. Can't help any further though, sorry. :(

Regards,
Sven

Is gdb or strace available on this system?

07.09.2014 15:50, Florian Klämpfl:

Yes. Both strace and gdb packages are available in openwrt (at least in the latest official release), they are just not included in typical released images (reasonable enough). One have to manually do:

opkg update
opkg install strace
opkg install gdb

HTH
Nikolai

Yes, I've got both of them installed as well as binutils.

strace ./hellomips
execve("./hellomips", ["./hellomips"], [/* 11 vars */]) = 0

that's it.

and
gdb ./hellomips

dlopen failed on 'libthread_db.so.1' - File not found GDB will not be able to debug pthreads.

GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details.
This GDB was configured as "mips-openwrt-linux"... (no debugging symbols found)
(gdb) run
Starting program: /usbstorage/backup/hellomips

I could recompile everything to use e.g. dwarf2 - remember doing that before but I think gdb complained about something else then. Still, happy to give it a go.

That's it? Nothing more? You could try to send a sigint (ctrl-c) and then ask for a backtrace (bt).

Or add a breakpoint on main first, and then run the appication. (b main)

Joost.

(gdb) run
Starting program: /usbstorage/backup/hellomips
^C
Program received signal SIGINT, Interrupt.
0x00401b20 in ?? ()
(gdb) bt
#0 0x00401b20 in ?? ()
warning: GDB can't find the start of the is unable to find the start of the function at 0x401b20 and thus can't determine the size of that function's stack frame. This means that GDB may be unable to access that stack frame, or the frames below it.
This problem is most likely caused by an invalid program counter or stack pointer.
However, if you think GDB should simply search farther back from 0x401b20 for code which looks like the beginning of a function, you can increase the range of the search using the `set heuristic-fence-post' command.
#1 0x00401b20 in ?? ()
warning: GDB can't find the start of the stopped: previous frame identical to this frame (corrupt stack?

Am 08.09.2014 18:28 schrieb "Reinier Olislagers" <

Could you please recompile FPC with OPT="-gl" (maybe also -O-) and compile your test program with that options as well and then retest the GDB run?

Regards,
Sven

Sven Barth wrote

Could you please recompile FPC with OPT="-gl" (maybe also -O-) and compile your test program with that options as well and then retest the GDB run?

Compiled cross-compiler:
opt="-O- -gl"
crossopt="-CpMIPS32R2 -CfSOFT"

Compiled program:
fpc -Tlinux -Pmips -CpMIPS32R2 -gl -O- hellomips.lpr

GDB run:
gdb ./hellomips

dlopen failed on 'libthread_db.so.1' - File not found GDB will not be able to debug pthreads.

GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details.
This GDB was configured as "mips-openwrt-linux"... (gdb) run
Starting program: /usbstorage/backup/hellomips
^C
Program received signal SIGINT, Interrupt.
GET_FSR () at C:/development/fpctrunk/rtl/mips/mips.inc:21 21 C:/development/fpctrunk/rtl/mips/mips.inc: No such file or directory.
in C:/development/fpctrunk/rtl/mips/mips.inc
Current language: auto; currently pascal
(gdb) bt
#0 GET_FSR () at C:/development/fpctrunk/rtl/mips/mips.inc:21 #1 0x00401b5c in SYSINITFPU () at
C:/development/fpctrunk/rtl/mips/mips.inc:61
#2 0x00401bd0 in FPC_CPUINIT ()
at C:/development/fpctrunk/rtl/mips/mips.inc:75
#3 0x00429bb8 in fpc_initializeunits ()
at C:/development/fpctrunk/rtl/inc/system.inc:872
#4 0x0040019c in main () at hellomips.lpr:16

Is this stacktrace always the same? Did you wait a bit until you used Ctrl+C?

Someone with more MIPS knowledge than me will need to look at this, though :)

Regards,
Sven

Am 08.09.2014 20:26 schrieb "Reinier Olislagers" <

I just had an interesting commit scroll past me in the Svn RSS feed. :) Could you please apply the changes from revision 28625 in branch branches/mips_embedded and recompile FPC and test again? http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&revision=28625

Since you're compiling with -CfSOFT this might be the solution.

Regards,
Sven

This smells like a problem I had on pic32. In my case the pic32 chips do not have a floating point unit and the processor creates an illegal instruction (or something similar) exception.

I solved this for me by patching out the call to the hardware coprocessor when softfpu is selected.

You could try this patch:

svn diff rtl/mips/mips.inc
Index: rtl/mips/mips.inc
=================================================================== --- rtl/mips/mips.inc (revision 28626)
+++ rtl/mips/mips.inc (working copy)
@@ -54,11 +54,12 @@

    fpu_rounding_minus_inf = 3;

    fpu_all_bits = fpu_enable_mask or fpu_flags_mask or fpu_cause_mask
or fpu_rounding_mask;
-
  {$define FPC_SYSTEM_HAS_SYSINITFPU}
  procedure SysInitFPU;
    begin
+{$ifndef FPC_HAS_FEATURE_SOFTFPU}
      set_fsr(get_fsr and (not fpu_all_bits) or (default_fpu_enable or
fpu_rounding_nearest));
+{$ENDIF FPC_HAS_FEATURE_SOFTFPU}
    end;
@@ -75,7 +76,6 @@
        SysInitFPU;
    end;
-
  {$ifndef INTERNAL_BACKTRACE}
  {$define FPC_SYSTEM_HAS_GET_FRAME}
  function get_frame:pointer;assembler;nostackframe;

Sven, you were faster than me ,-)

Michael

Hi,
09.09.2014 0:54, Sven Barth:
[...]

http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&revision=28625 <http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&revision=28625> Since you're compiling with -CfSOFT this might be the solution.

BTW, the kernel on the devel mips box has the option "Algorithmics/MIPS Emulator" enabled (as otherwise debian refused to run), this probably explains why testsuite mostly succeeded whereas FPU is actually not present there.
IIRC this is essentially the only relevant change from default openwrt kernel I had to make, so I'd bet you are right.

Nikolai

Which should be the correct approach for softfpu anyway. Afterall the premise of softfpu is that there is no hardware FPU to use and thus corresponding CPU instructions are useless (or as it seems in this case lead to nothing).

Regards,
Sven

Applied a similar patch [1]; progress, thanks!

gdb bt now shows:
^C
Program received signal SIGINT, Interrupt.
fpc_setjmp (S=
{RA = 4398704, SP = 2139211400, S0 = 2130823600, S1 = 5034972, S2 = 5035028, S3 = 4571000, S4 = 2000557128, S5 = 4587520, S6 = 4589204, S7 = 5034940, FP = 2139211632, GP = 4589264, _FCSR = 0, F20 = 0, F21 = 0, F22 = 0, F23 = 0, F24 = 0, F25 = 0, F26 = 4563944, F27 = 4, F28 = 4563944, F29 = 4563947, F30 = 0, F31 = 0}) at
C:/development/fpctrunk/rtl/mips/setjump.inc:68
68 C:/development/fpctrunk/rtl/mips/setjump.inc: No such file or directory.
in C:/development/fpctrunk/rtl/mips/setjump.inc
Current language: auto; currently pascal
(gdb) bt
#0 fpc_setjmp (S=
{RA = 4398704, SP = 2139211400, S0 = 2130823600, S1 = 5034972, S2 = 5035028, S3 = 4571000, S4 = 2000557128, S5 = 4587520, S6 = 4589204, S7 = 5034940, FP = 2139211632, GP = 4589264, _FCSR = 0, F20 = 0, F21 = 0, F22 = 0, F23 = 0, F24 = 0, F25 = 0, F26 = 4563944, F27 = 4, F28 = 4563944, F29 = 4563947, F30 = 0, F31 = 0}) at
C:/development/fpctrunk/rtl/mips/setjump.inc:68
#1 0x00431e70 in ASSIGN (T=
{HANDLE = 0, MODE = 0, RECSIZE = 0, _PRIVATE = #0 <repeats 31 times>, USERDATA = #0 <repeats 31 times>, NAME = #0 <repeats 255 times>}, S=Cannot access memory at address 0xd7b1
)
at C:/development/fpctrunk/rtl/inc/text.inc:127
#2 0x00439edc in OPENSTDIO (F=Cannot access memory at address 0x0 )
at C:/development/fpctrunk/rtl/inc/text.inc:2644
#3 0x0043f09c in SYSINITSTDIO () at system.pp:276 #4 0x0043f4d0 in SYSTEM_$$_init () at system.pp:364 #5 0x00429c10 in fpc_initializeunits ()
at C:/development/fpctrunk/rtl/inc/system.inc:888
#6 0x0040019c in main () at hellomips.lpr:16

[1]
Index: rtl/mips/mips.inc
=================================================================== --- rtl/mips/mips.inc (revision 28619)
+++ rtl/mips/mips.inc (working copy)
@@ -58,7 +58,9 @@
{$define FPC_SYSTEM_HAS_SYSINITFPU}
procedure SysInitFPU;

   begin

+{$ifndef FPC_HAS_FEATURE_SOFTFPU}
set_fsr(get_fsr and (not fpu_all_bits) or (default_fpu_enable or fpu_rounding_nearest));
+{$ENDIF FPC_HAS_FEATURE_SOFTFPU}

   end;

09.09.2014 9:53, Sven Barth пишет:

This patch is correct only if the goal is do disable floating-point completely. If the goal is to have floating-point calculations available using emulation, then the entire procedures SysInitFPU and SysResetFPU together with {$define FPC_SYSTEM_HAS_SYSRESETFPU} and {$define FPC_SYSTEM_HAS_SYSINITFPU} must be disabled. Doing so will cause softfpu-specific routines from generic.inc to be used.

I also wonder what is the correct way to generate code that calls softfpu:
1) -SfSOFTFPU
2) -CfSOFT
3) -Ce
?

Regards,
Sergei

I was wondering whether a completely empty program would be a better test than a "Hello, World!". Could a completely empty program be recognised by the compiler etc. as a special case and built with only minimal RTL initialisation, specifically as a test that a program will load and terminate in good order i.e. that FPC and the OS are compatible? Or is there a set of portable options that will already do this, which could be documented prominently?

After all, there's been comparable issues on ARM, and there might be more on various platforms in the future.

On Tue, September 9, 2014 10:20, Mark Morgan Lloyd wrote: .
.

Isn't there a risk that behaviour of a program not doing anything might look the same as behaviour of a program failing/crashing before doing what it was asked to do?

In addition, what is the supposed difference between an "empty program" and program "built with only minimal RTL initialisation"?

Tomas

premise of softfpu is that

> there is no hardware FPU to use and thus corresponding CPU instructions

are useless (or as it seems

> in this case lead to nothing). > This patch is correct only if the goal is do disable floating-point

completely. If the goal is to have floating-point calculations available using emulation, then the entire procedures SysInitFPU and SysResetFPU together with {$define FPC_SYSTEM_HAS_SYSRESETFPU} and {$define FPC_SYSTEM_HAS_SYSINITFPU} must be disabled. Doing so will cause softfpu-specific routines from generic.inc to be used.

Well, according to Reinier's test at least the route seems to be correct. So we need to ensure that softfpu code for MIPS works correctly.

I only know -CfSOFT and that is what I use for m68k. -Ce likely only does the same as -CfSOFT, but I don't know what -SfSOFTFPU is supposed to do.

Regards,
Sven

Am 09.09.2014 10:30 schrieb "Mark Morgan Lloyd" <

premise of softfpu is that there is no hardware FPU to use and thus corresponding CPU instructions are useless (or as it seems in this case lead to nothing).

I was wondering whether a completely empty program would be a better test

than a "Hello, World!". Could a completely empty program be recognised by the compiler etc. as a special case and built with only minimal RTL initialisation, specifically as a test that a program will load and terminate in good order i.e. that FPC and the OS are compatible? Or is there a set of portable options that will already do this, which could be documented prominently?

No strange automatisms please. If one wants a minimal RTL initialization then one should explicitly disable code in the System unit and rebuild. Period.

Regards,
Sven

09.09.2014 13:19, Sven Barth пишет:

Well, for m68k you can omit -CfSOFT and nothing will change, because currently nothing else is supported there.
As for -Ce, the compiler code sometimes checks for it (cs_fp_emulation in current_settings.moduleswitches), sometimes for -CfSOFT (current_settings.fputype=fpu_soft), sometimes for both. That's why I wonder.
-SfSOFTFPU is for embedded targets where it enables "softfpu feature", for non-embedded targets it is assumed to be permanently present (?), but again it's unclear if this feature replaces hardware FPU (if present) or appends to it.

Regards,
Sergei

I don't see why something like this

program test;
begin
end.

should use anything other than the absolute minimum that's needed to terminate in good order. At that point gdb (or strace etc.) should be able to confirm that it's terminated rather than crashing, and that would be useful confirmation that as far as the OS and system libraries were concerned the binary format (ELF header etc.) was OK.

After all, when this sort of problem has been raised in the past we've usually started off by scratching our heads over whether the user had somehow screwed the file, or had built it with the wrong endianness or for an inappropriate CPU. It would be useful to be able to eliminate some of these possible conditions.

This problem also looks similar, there are two procedures in setjump.inc and they both address the fpu:

ctc1 $v0,$31

cfc1 $v0,$31

Michael

Sergei, I have reworked the patch based on your comment:

http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&revision=28634

Do you think this is solved better now?

Michael

Michael Ring wrote

This problem also looks similar, there are two procedures in setjump.inc and they both address the fpu:

Thanks.

Patched [1] setjump.inc and now get
#0 fpc_setjmp (S=
{RA = 4398696, SP = 2143770920, S0 = 2135383120, S1 = 12489692, S2 = 12489748, S3 = 4571000, S4 = 1997669448, S5 = 4587520, S6 = 4589204, S7 = 12489660, FP = 2143771152, GP = 4589248, _FCSR = 2143771044, F20 = 0, F21 = 0, F22 = 0, F23 = 0, F24 = 0, F25 = 0, F26 = 4563928, F27 = 4, F28 = 4563928, F29 = 4563931, F30 = 0, F31 = 0}) at C:/development/fpctrunk/rtl/mips/setjump.inc:74
#1 0x00431e68 in ASSIGN (T=
{HANDLE = 0, MODE = 0, RECSIZE = 0, _PRIVATE = #0 <repeats 31 times>, USERDATA = #0 <repeats 31 times>, NAME = #0 <repeats 255 times>}, S=Cannot access memory at address 0xd7b1
)
at C:/development/fpctrunk/rtl/inc/text.inc:127

Line 74 in my patched setjump.inc and further:

    swc1  $f20,jmp_buf.f20($a0)
    swc1  $f21,jmp_buf.f21($a0)
    swc1  $f22,jmp_buf.f22($a0)
    swc1  $f23,jmp_buf.f23($a0)
    swc1  $f24,jmp_buf.f24($a0)
    swc1  $f25,jmp_buf.f25($a0)
    swc1  $f26,jmp_buf.f26($a0)
    swc1  $f27,jmp_buf.f27($a0)
    swc1  $f28,jmp_buf.f28($a0)
    swc1  $f29,jmp_buf.f29($a0)
    swc1  $f30,jmp_buf.f30($a0)
    swc1  $f31,jmp_buf.f31($a0)
    move  $v0,$zero
  end;

[1]
Index: rtl/mips/setjump.inc
=================================================================== --- rtl/mips/setjump.inc (revision 28633)
+++ rtl/mips/setjump.inc (working copy)
@@ -28,7 +28,9 @@
lw $fp,jmp_buf.fp($a0)
lw $gp,jmp_buf.gp($a0)
lw $v0,jmp_buf._fcsr($a0)
+{$ifndef FPC_HAS_FEATURE_SOFTFPU}
ctc1 $v0,$31
+{$endif}
lwc1 $f20,jmp_buf.f20($a0)
lwc1 $f21,jmp_buf.f21($a0)
lwc1 $f22,jmp_buf.f22($a0)
@@ -65,7 +67,9 @@
sw $s7,jmp_buf.s7($a0)
sw $fp,jmp_buf.fp($a0)
sw $gp,jmp_buf.gp($a0)
+{$ifndef FPC_HAS_FEATURE_SOFTFPU}
cfc1 $v0,$31
+{$endif}
sw $v0,jmp_buf._fcsr($a0)
swc1 $f20,jmp_buf.f20($a0)
swc1 $f21,jmp_buf.f21($a0)

If you compile an empty program, the compiler doesn't add anything except for initialization of standard RTL features included in unit System. As pointed out by Sven, it's possible to disable various RTL features (obviously including their initialization) using IFDEFs. Asking for the compiler to detect that your program isn't using certain RTL features and thus bypass initialization of such features looks very tricky to me.

Regarding gdb or strace as means for confirmation of properly loading and running binaries - I wouldn't assume that all devices used for running FPC programs need to have these installed and sometimes it's really matter of finding out why something doesn't work on that particular device. Obviously, it's still an option, but I wouldn't say that it's a better one unless there's some doubt that the issue may indeed be related to initialization of a specific RTL feature (but even then one still needs to find out which particular one it is).

Tomas

In our previous episode, Mark Morgan Lloyd said:

Well, first you must realize that that program is equal to

program test;
Uses System;
begin
  FPC_INITIALIZEUNITS;
  // nothing
  FPC_FINALIZEUNITS;
end.

The FPC_* routines walk tables and call the all units' initialization and finalization sections. In this case System's.

Your observation reduces to letting the compiler figuring out that in the system unit initialization the FPU Initialization can be safely skipped, and that possible state (like the FPU control word) is not important.

This is nearly impossible.

In fairness, my original question was "Could a completely empty program be recognised by the compiler etc. as a special case". So what you're saying- entirely fairly- is that because of the "Uses System" the problem is probably intractable.

But could the "Uses system" be omitted or replaced by a simpler stub if the program was recognised to be trivial?

09.09.2014 14:33, Michael Ring пишет:

No, my point was that routines SysInitFPU and SysResetFPU from inc/generic.inc must be called instead of ones in mips/mips.inc. Therefore changes to fpc_cpuinit aren't necessary.

Regards,
Sergei

In our previous episode, Mark Morgan Lloyd said:

No, not really. The problem is that the system unit (including its initializer routine) is already available precompiled. Even if you have a detection, there is no possibility with current formats to walk through the initialization and say "yes, do this, but not do that".

The linker works purely on sections refering sections, and that initialization is a section. Probably the initialization of the system unit should be converted to some table that can somehow be reduced by the linker or generated by the compiler while compiling the main program, when all caveats are known.

But could the "Uses system" be omitted or replaced by a simpler stub if the program was recognised to be trivial?

Multiple RTLs is another solution yes. But when the compiler reaches "begin..end" the system unit is already loaded, so that's too late, so you would have to force that on the commandline or with a $directive before the uses. Then we might as well pass a different RTL path (with -n -Fu) directly instead of making special allowances and detections.

And at that point it basically reduces to what is currently done when porting, simply commenting the offending lines in system during initial porting. A whole lot easier :-)

"Sven Barth" wrote

Am 09.09.2014 08:53 schrieb "Sergei Gorelkin" : > I also wonder what is the correct way to generate code that calls

softfpu:

the same as -CfSOFT, but I don't know what -SfSOFTFPU is supposed to do.

Addendum: -SfX is for explicitly enabling RTL features, likely added for embedded. Also one *might* need to use both -CfSOFT and -Ce on MIPS as they set different values. I've not yet checked what the explicit difference is :/

Regards,
Sven

This asks for a small comment:
If (one day) it should be possible to use fpc functions as code callable by C a function maintained in the Microchip IDE universe (which is what I some day hope top be able to use or make happen), it should be possible to call the C rtl floating point emulation instead of re-doing them in the fpc rtl.

-Michael

I checked the compile of system.pp for mipsel-embedded with the compile option -vc to see the status of the defines in order to find out the correct way to get SysResetFPU and SysInitFPU called.

As mips.inc is parsed before generic.inc fpc_cpuunit must get defined out because if not compilation breaks as the correct versions are defined later in generic.inc.

I also saw a second call for initialization in rtl/embedded/system.pp:

{$ifdef FPC_HAS_FEATURE_FPU}
   { Beware: The same code is executed from fpc_cpuinit, which is included
     per-cpu unconditionally }
   SysResetFPU;
   if not(IsLibrary) then
     SysInitFPU;
{$endif FPC_HAS_FEATURE_FPU}

This place looks perfect, only thing is that I do not know the meaning of FPC_HAS_FEATURE_FPU.

If this means "System has FPU, do not care if it is hard ord soft fpu" then I guess the way to do things would be to define FPC_HAS_FEATURE_FPU together with FPC_HAS_FEATURE_SOFTFPU

But what makes me struggle is that I also see a lot of occurences of the define FPUNONE, so I guess my interpretation above is wrong.

I also did a complete grep for FPC_HAS_FEATURE_FPU

find fpc-mipsel -type f -exec grep -H "FPC_HAS_FEATURE_FPU" {} \;

./rtl/embedded/system.pp:{$ifdef FPC_HAS_FEATURE_FPU} ./rtl/embedded/system.pp:{$endif FPC_HAS_FEATURE_FPU}

and it is only used in ./rtl/embedded/system.pp,

could the solution be as simple as to *replace FPC_HAS_FEATURE_FPU with FPC_HAS_FEATURE_SOFTFPU* ?

puzzled,

Michael

Reinier Olislagers wrote

Periodically I try to cross-compile a simple program [1] for my router with fpc trunk.

Recap: mips big endian, no FPU (openwrt router). Test program hung.

Thanks to commits in trunk between my last test and now, the sample program below works.
-Tlinux -Pmips -CpMIPS32R2 -gw2 -g -CfSOFT

Thanks, everyone! Now for some more complicated programs and perhaps I'll be back ;)

program hellomips;
{$mode objfpc}
{$H+}

{not$DEFINE UseCThreads} //otherwise it seems we get pthreads which gdb can't debug

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Sysutils, Classes
  ;
begin
  writeln('hello mips');
end.

Reinier Olislagers wrote

Periodically I try to cross-compile a simple program [1] for my router with fpc trunk.

Recap: mips big endian, no FPU (openwrt router). Test program hung.

Thanks to commits in trunk between my last test and now, the sample program below works.
-Tlinux -Pmips -CpMIPS32R2 -gw2 -g -CfSOFT

Thanks for the help and commits everyone! Now for some more complicated programs and perhaps I'll be back ;)

program hellomips;
{$mode objfpc}
{$H+}

{not$DEFINE UseCThreads} //otherwise it seems we get pthreads which gdb can't debug

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Sysutils, Classes
  ;
begin
  writeln('hello mips');
end.