Re: [fpc-devel] Crash while compiling fpc 2.7.1 on ARM
Le 2013-05-28 22:41, Paul Ishenin a écrit : 29.05.2013 10:09, Michel Catudal пишет: My platform is odroid U2 with funtoo Linux, desktop is mate. Processor is a 4 core arm processor from Samsung, running at 1.7Ghz with 2G of RAM, OS runs on a 32G SD Card. I also have an Ubuntu system also on a 32G SD card, haven't tested fpc compile on it yet. A few weeks ago I was able to compile fpc with hard float support on odroid U2. I still have it along with lazarus. I have created a few graphic programs, they work like a champ so far, no crash. For the past few weeks fpc no longer compiles. It works until it is time to compile the RTL. What starting compiler do you use? Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel The one that I compiled before the code was broken -- For Linux Software visit http://home.comcast.net/~mcatudal ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Crash while compiling fpc 2.7.1 on ARM
29.05.2013 14:06, Michel Catudal пишет: The one that I compiled before the code was broken To answer on your question I need to know paticular compiler version. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Crash while compiling fpc 2.7.1 on ARM
Hi, On Wed, 2013-05-29 at 15:01 +0800, Paul Ishenin wrote: 29.05.2013 14:06, Michel Catudal пишет: The one that I compiled before the code was broken (note: the last working armhf compiler was generated by daily builds on 8th of May) To answer on your question I need to know paticular compiler version. Probably 2.7.1 as 2.6.2 cannot generate armhf code; that is the same issue I was reporting elsewhere. Naturally it is most convenient to compile on the device natively, especially since arm devices are fast enough now. Unfortunately the latest stable version is too outdated to support that. @Michel: I got the following response recently: [.. the same crash description ...] Only when compiling with trunk as starting compiler with -O2 (i.e. default settings). I do know that compiling with trunk is unsupported, but with 2.6.2 you - cannot compile for armv7a (armv7-a, armv7 etc) - cannot compile for/on armhf Regardless, this seems to be an (old) optimizer bug in trunk which would be nice if it were fixed regardless of that. Sorry, also occurs with OPT=-O- That's true, RTTI on alignment-sensitive targets was not generated correctly. I fixed that (or at least tried to) in r24562, getting a working compiler for MIPS. Can you test if r24562 fixes behavior on ARM? (You have to build trunk for i386 using 2.6.2, then use that compiler to cross-compile for armv7). I did not have time to test this workaround yet. So try to first build a non-armhf version, and then crosscompile to armhf. You can try using this method to get a new base compiler. Hth, Thomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Some Opcodes missing in internal assembler for mips32r2
29.05.2013 2:08, Sergei Gorelkin пишет: 29.05.2013 1:26, Michael Ring пишет: I did the changes, parts of the opcodes now work fine, I think I have found the problem with the li + and + mfc0 op-codes, if last parameter is 0 then the asm statement is generated wrong: This works: and$a0,$a0,1 this does not work: and$a0,$a0,0 result is: pic32mx1xxfxxxb.s:107: Error: absolute expression required `and $a0,$a0,' So it is the value of operand that matters. I'll try to look at it, probably a bug in the parsing part, because the output part doesn't have anything suspicious. Fixed in r24630. The parsing part is buggy as hell (it interprets numbers as references rather than as constants), but the output part wasn't correct either at outputting such references. Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Crash while compiling fpc 2.7.1 on ARM
Le 2013-05-29 03:01, Paul Ishenin a écrit : 29.05.2013 14:06, Michel Catudal пишет: The one that I compiled before the code was broken To answer on your question I need to know paticular compiler version. Best regards, Paul Ishenin Here is more detailed info. I guess my answer was a bit too short, I did a quick answer last night after I finally got firefox 20.0.1 compiled on odroid U2. The ebuild that comes with funtoo has probably never been tried on ARM, a few things would compiled, the patch were minimal. If anyone is interested I can give my patches. When I installed funtoo I compiled fpc-2.6.0 which came with the standard funtoo portage That version worked but lazarus would not work with it. I then went on to compile the dev version 2.7.1 , it would crash. The strange part is that a few weeks prior it would compile fine on mele A2000G. I passed the arguments for hard float, that is how I got lazarus to work. I did some experiment and found out that the fpc.zip snapshot still worked while the fpcbuild.zip one would crash. I didn't realize until a bit later that I needed to erase the manifest file and move the fpc.zip file from the distfiles directory to force it to use the latest snapshot. This is why it worked. Once I recreated the manifest file on the ebuild directory the compiling would no longer work. When I compared the fpc.zip to the code in fpcbuild I saw that they didn't match at all. I am not sure that this fpc.zip is the last one that worked. It is dated may 6th. part of the ebuild that worked : HOMEPAGE=http://www.freepascal.org/; DESCRIPTION=Free Pascal Compiler SRC_URI=ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/source/fpc.zip; SLOT=0 I had to copy the source on a directory that would satisfy lazarus since this is not the standard fpcbuild code. revision may 6th : URL: http://svn.freepascal.org/svn/fpc/trunk Revision: 24455 Last Changed Rev: 24455 Here is when I run fpc, the date shown is the date that the compiler was created michel@michel /usr/local/portage/dev-lang/fpc $ fpc Free Pascal Compiler version 2.7.1 [2013/05/18] for arm Copyright (c) 1993-2013 by Florian Klaempfl and others Here is the newer one michel compiler # pwd /var/tmp/portage/dev-lang/fpc-2.7.1-r2/work/fpcbuild/fpcsrc/compiler michel compiler # ./ppc1 Free Pascal Compiler version 2.7.1 [2013/05/28] for arm Copyright (c) 1993-2013 by Florian Klaempfl and others This one is crashes trying to create the RTL files. I made sure that it took the lastest snapshot. Perhaps there should be a date in the filename so it would be easier to track. With the version that I have that works, I have done a few test and it never crashes. I didn't do very extensive tests yet. I was more concerned with getting something that someone else would be able to create without me having to provide some forked version. There may well be issues, I will do more tests later on. Michel -- For Linux Software visit http://home.comcast.net/~mcatudal ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Some Opcodes missing in internal assembler for mips32r2
This is looking good now on first view, all statements seem to pass through now. The only thing not working is the register error in mfc0 (and friends) command. Now I will wade through some more code to find out why my nice param -CpMIPS32R2 is ignored by assembler, it still defaults to MIPS2: Target OS: Embedded Compiling pic32mx1xxfxxxb.pp Assembling pic32mx1xxfxxxb pic32mx1xxfxxxb.s: Assembler messages: pic32mx1xxfxxxb.s:37: Error: Illegal operands `mfc0 $t0,$t4,1' pic32mx1xxfxxxb.s:38: Error: Opcode not supported on this processor: mips2 (mips2) `ext $t0,$t0,19,1' pic32mx1xxfxxxb.s:49: Error: Opcode not supported on this processor: mips2 (mips2) `ext $t2,$t1,26,4' pic32mx1xxfxxxb.s:51: Error: Opcode not supported on this processor: mips2 (mips2) `ins $t1,$t2,6,4' Thank you for your help! Michael Am 29.05.13 18:13, schrieb Sergei Gorelkin: 29.05.2013 2:08, Sergei Gorelkin пишет: 29.05.2013 1:26, Michael Ring пишет: I did the changes, parts of the opcodes now work fine, I think I have found the problem with the li + and + mfc0 op-codes, if last parameter is 0 then the asm statement is generated wrong: This works: and$a0,$a0,1 this does not work: and$a0,$a0,0 result is: pic32mx1xxfxxxb.s:107: Error: absolute expression required `and $a0,$a0,' So it is the value of operand that matters. I'll try to look at it, probably a bug in the parsing part, because the output part doesn't have anything suspicious. Fixed in r24630. The parsing part is buggy as hell (it interprets numbers as references rather than as constants), but the output part wasn't correct either at outputting such references. Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Accepted fpc 2.6.2-1 (source amd64 all)
For those reading this on fpc-devel the context is that the upload of fpc 2.6.2 to debian failed on most architectures and I would like upstream input on sorting it out. Abou Al Montacir wrote: Many targets are broken: powerpc, sparc, armel, armhf. The error message looks very similar on 3 targets (powerpc, sparc and armel) but not for armhf. I've sorted the armhf specific issue. As expected it just required some tweaking of ifdefs so that the code in question wasn't used when building the rtl with 2.6.0. After sorting that issue it failed with much the same linker problem with fpmake as other architectures. /usr/bin/make -C fastcgi smart make[3]: Entering directory `/«PKGBUILDDIR»/fpcsrc/packages/fastcgi' /«PKGBUILDDIR»/fpcsrc/compiler/ppcppc fpmake.pp -n -Fu/«PKGBUILDDIR»/fpcsrc/rtl/units/powerpc-linux -Fu/«PKGBUILDDIR»/fpcsrc/packages/hash/units/powerpc-linux -Fu/«PKGBUILDDIR»/fpcsrc/packages/paszlib/units/powerpc-linux -Fu/«PKGBUILDDIR»/fpcsrc/packages/fcl-process/units/powerpc-linux -Fu/«PKGBUILDDIR»/fpcsrc/packages/fpmkunit/units/powerpc-linux /usr/bin/ld: warning: link.res contains output sections; did you forget -T? /usr/lib/powerpc-linux-gnu/libc_nonshared.a(elf-init.oS): In function `__libc_csu_init': (.text+0x48): undefined reference to `_init' fpmake.pp(30,38) Error: Error while linking fpmake.pp(30,38) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted make[3]: *** [fpmake] Error 1 make[3]: Leaving directory `/«PKGBUILDDIR»/fpcsrc/packages/fastcgi' make[2]: *** [fastcgi_smart] Error 2 make[2]: Leaving directory `/«PKGBUILDDIR»/fpcsrc/packages' make[1]: *** [packages_smart] Error 2 make[1]: Leaving directory `/«PKGBUILDDIR»/fpcsrc' make: *** [build-arch-stamp] Error 2 dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2 At a first look, it seems related to a particular component (fastcgi), but deeper look shows that this is the first package being compiled using fpmake (new FP make like utility). The error itself happens while compiling fpmake at link stage. I figured out the cause of this one. To successfully link against libc on many platforms (but NOT i386 and amd64) fpc needs to find certain libraries (/usr/lib/crt?.o iirc). To make things more confusing if it doesn't find them it silently leaves them out of the linker script and the build fails with missing symbol errors. This was discovered some time ago. On debian versions that support multiarch the libraries in question can be found in /usr/lib/multiarch triplet For programs that users build we got arround this some time ago by adding a line to fpc.cfg but that doesn't work for stuff that is built as part of the build process itself like fpmake because the fpc build process (deliberately) ignores fpc.cfg. So the option to make it look int the right place needs to be passed in explicitly. Unfortunately I haven't managed to make the fpc build process pass that in. I vaugely remember an option called something like FPMAKEOPT but I can't seem to find any evidence of it in the 2.6.2 source tree. Another way of solving the problem would be to add /usr/lib/multiarch triplet to the paths that are baked into the compiler (as is done for gcc in debian). IMO this is the best soloution but last time I mentioned this to upstream they didn't seem to keen on the idea. Yet another option would be to disable threading support in fpmake but i'd rather not go down that road. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
