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
On 09/08/2014 10:54 PM, Michael Ring wrote:
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
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 =
09.09.2014 9:53, Sven Barth пишет:
On 08.09.2014 22:54, Michael Ring wrote:
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
Sven Barth wrote:
On 08.09.2014 22:54, Michael Ring wrote:
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
On Tue, September 9, 2014 10:20, Mark Morgan Lloyd wrote:
.
.
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,
Am 09.09.2014 08:53 schrieb Sergei Gorelkin sergei_gorel...@mail.ru:
09.09.2014 9:53, Sven Barth пишет:
On 08.09.2014 22:54, Michael Ring wrote:
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
Am 09.09.2014 10:30 schrieb Mark Morgan Lloyd
markmll.fpc-de...@telemetry.co.uk:
Sven Barth wrote:
On 08.09.2014 22:54, Michael Ring wrote:
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
09.09.2014 13:19, Sven Barth пишет:
Am 09.09.2014 08:53 schrieb Sergei Gorelkin sergei_gorel...@mail.ru
mailto:sergei_gorel...@mail.ru:
09.09.2014 9:53, Sven Barth пишет:
On 08.09.2014 22:54, Michael Ring wrote:
This smells like a problem I had on pic32. In my case the pic32 chips do
Tomas Hajny wrote:
On Tue, September 9, 2014 10:20, Mark Morgan Lloyd wrote:
.
.
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
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
Am 09.09.14 um 08:29 schrieb Reinier Olislagers:
Applied a similar patch [1]; progress, thanks!
gdb bt now shows:
^C
Program received signal
Sergei, I have reworked the patch based on your comment:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revisionrevision=28634
Do you think this is solved better now?
Michael
Am 09.09.14 um 08:52 schrieb Sergei Gorelkin:
09.09.2014 9:53, Sven Barth пишет:
On 08.09.2014 22:54, Michael
On 09/09/2014 12:08, 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
On Tue, September 9, 2014 12:00, Mark Morgan Lloyd wrote:
Tomas Hajny wrote:
On Tue, September 9, 2014 10:20, Mark Morgan Lloyd wrote:
.
.
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
In our previous episode, Mark Morgan Lloyd said:
In addition, what is the supposed difference between an empty program
and program built with only minimal RTL initialisation?
I don't see why something like this
program test;
begin
end.
should use anything other than the absolute
Marco van de Voort wrote:
In our previous episode, Mark Morgan Lloyd said:
In addition, what is the supposed difference between an empty program
and program built with only minimal RTL initialisation?
I don't see why something like this
program test;
begin
end.
should use anything other than
09.09.2014 14:33, Michael Ring пишет:
Sergei, I have reworked the patch based on your comment:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revisionrevision=28634
Do you think this is solved better now?
No, my point was that routines SysInitFPU and SysResetFPU from inc/generic.inc must
In our previous episode, Mark Morgan Lloyd said:
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
Am 09.09.2014 11:19 schrieb Sven Barth pascaldra...@googlemail.com:
Am 09.09.2014 08:53 schrieb Sergei Gorelkin sergei_gorel...@mail.ru:
I also wonder what is the correct way to generate code that calls
softfpu:
1) -SfSOFTFPU
2) -CfSOFT
3) -Ce
?
I only know -CfSOFT and that is what I
On 07/09/2014 23:12, Nikolai Zhubr wrote:
07.09.2014 15:50, Florian Klämpfl:
Is gdb or strace available on this system?
Yes. Both strace and gdb packages are available in openwrt (at least in
the latest official release),
Yes, I've got both of them installed as well as binutils.
strace
On 09/08/2014 10:25 AM, Reinier Olislagers wrote:
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
On 08/09/2014 18:01, Joost van der Sluis wrote:
On 09/08/2014 10:25 AM, Reinier Olislagers wrote:
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+:
Am 08.09.2014 18:28 schrieb Reinier Olislagers
reinierolislag...@gmail.com:
On 08/09/2014 18:01, Joost van der Sluis wrote:
On 09/08/2014 10:25 AM, Reinier Olislagers wrote:
gdb ./hellomips
dlopen failed on 'libthread_db.so.1' - File not found
GDB will not be able to debug pthreads.
On 08/09/2014 20:05, 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
On 08.09.2014 20:25, Reinier Olislagers wrote:
(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
Am 08.09.2014 20:26 schrieb Reinier Olislagers
reinierolislag...@gmail.com:
On 08/09/2014 20:05, 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:
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
Sven, you were faster than me ,-)
Michael
Am 08.09.14 um 22:54 schrieb Sven Barth:
Am 08.09.2014 20:26 schrieb Reinier Olislagers
reinierolislag...@gmail.com mailto:reinierolislag...@gmail.com:
On 08/09/2014 20:05, Sven Barth wrote:
Could you please recompile FPC with OPT=-gl (maybe
Hi,
09.09.2014 0:54, Sven Barth:
[...]
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revisionrevision=28625
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revisionrevision=28625
Since you're compiling with -CfSOFT this might be the solution.
BTW, the kernel on the devel mips box has
On 08.09.2014 22:54, Michael Ring wrote:
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
On 06/09/2014 22:38, Sven Barth wrote:
Am 06.09.2014 11:27 schrieb Reinier Olislagers
reinierolislag...@gmail.com mailto:reinierolislag...@gmail.com:
Would you please as a test remove the Classes unit as well? It does some
rather heavyweight initialization (which I noticed during getting m68k
On 07/09/2014 11:24, 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 0x0102:
EXEC_P, D_PAGED
Am 07.09.2014 11:25 schrieb Reinier Olislagers
reinierolislag...@gmail.com:
On 06/09/2014 22:38, Sven Barth wrote:
Am 06.09.2014 11:27 schrieb Reinier Olislagers
reinierolislag...@gmail.commailto:reinierolislag...@gmail.com:
Would you please as a test remove the Classes unit as well? It
Am 07.09.2014 um 13:49 schrieb Sven Barth:
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. :(
Is gdb or
07.09.2014 15:50, Florian Klämpfl:
Am 07.09.2014 um 13:49 schrieb Sven Barth:
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
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
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
Reinier Olislagers wrote:
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.
I think the previous discussion
On 06/09/2014 12:20, Mark Morgan Lloyd wrote:
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
06.09.2014 14:53, Reinier Olislagers пишет:
On 06/09/2014 12:20, Mark Morgan Lloyd wrote:
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
Arggghhh. Ok, thanks, Sergei!
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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
Reinier Olislagers wrote:
On 06/09/2014 12:20, Mark Morgan Lloyd wrote:
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
On 06/09/2014 18:40, Nikolai Zhubr wrote:
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
Am 06.09.2014 11:27 schrieb Reinier Olislagers
reinierolislag...@gmail.com:
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,
45 matches
Mail list logo
