Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
That may be true, but takes tricks. The compiler from me WILL build trunk, because it is a trunk. I do not have much time but as I stated before i WILL update it. It just takes a bit longer. Also, I won't do a full .deb for it, unless some helps with that. I wasn't able to do that yet and do not have experience with package building for Debian.. My starting compiler still will compile trunk with OVERRIDEVERSIONCHECK=1. This is a temporary solution until 2.8 is released and the debian guys will accept the latest stable 2.8 (which is a long way off, I understand): debian won't accept 2.71, because it is experimental. Raspbian follows Debeian. Debian is rightfully slow in accepting anything but the most stable and release versions. Debian will almost never accept anything else. Point is: to obtain best results on the Raspberry Pi, you WILL need the latest FPC. It is really a great compiler for the platform. The instructions I wrote still work as of 28898 (todays checkout) Thaddy On 10/23/2014 2:11 AM, peter green wrote: Pierre Free Pascal wrote: https://archive.raspbian.org/raspbian/pool/main/f/fpc/ The 2.6.4 release is able to successfully compile a 2.7.1 trunk compiler. :) Thanks for confirming. Several files are missing in this source release: The source package which is made up of fpc_2.6.4+dfsg-4+rpi1.dsc , fpc_2.6.4+dfsg-4+rpi1.debian.tar.xz and fpc_2.6.4+dfsg.orig.tar.gz does contain the files you mention. To extract it you use dpkg-source -x on the dsc file. This is the source used to build the deb files. The binary package fpc-source exists primerally for the benefit of lazarus users, it appears to contain more than is needed for lazarus use but not enough to actually build the compiler which does seem a bit strange. This is not raspbian specific, the packages in debian are the same way. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
Jonas, In that case I would advice people to use my version of 2.7.1 for the Raspberry Pi and let me deal with any build difficulties. I am fully aware you removed the OVERRIDEVERSIONCHECK from the documentation. The most recently published build by me takes full advantage of most of the features for ARMV6 EABIHF. Plz advice on how to progress, Thaddy On 10/23/2014 10:25 AM, Jonas Maebe wrote: On 23/10/14 10:18, Thaddy de Koning wrote: That may be true, but takes tricks. Your OVERRIDEVERSIONCHECK=1 is also a trick (and a really bad one). The compiler from me WILL build trunk, because it is a trunk. Please don't make such broad statements. We already get enough bug reports about people trying to build trunk with another trunk version and failing. To clarify: trunk revision X is only guaranteed to be able to build that same trunk revision X. It is also guaranteed to fail when trying to build other trunk revisions at least some of the time. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
At the moment, there is not a good, publicly available, starting compiler other than my unofficial builds. The real starting compiler has never been public AFAIK. Maybe the guy(s) or/and girl(s) who have done the original build for the Raspberry Pi can shed a light on that one... On 10/23/2014 10:55 AM, Thaddy de Koning wrote: Jonas, In that case I would advice people to use my version of 2.7.1 for the Raspberry Pi and let me deal with any build difficulties. I am fully aware you removed the OVERRIDEVERSIONCHECK from the documentation. The most recently published build by me takes full advantage of most of the features for ARMV6 EABIHF. Plz advice on how to progress, Thaddy On 10/23/2014 10:25 AM, Jonas Maebe wrote: On 23/10/14 10:18, Thaddy de Koning wrote: That may be true, but takes tricks. Your OVERRIDEVERSIONCHECK=1 is also a trick (and a really bad one). The compiler from me WILL build trunk, because it is a trunk. Please don't make such broad statements. We already get enough bug reports about people trying to build trunk with another trunk version and failing. To clarify: trunk revision X is only guaranteed to be able to build that same trunk revision X. It is also guaranteed to fail when trying to build other trunk revisions at least some of the time. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
On 23/10/14 10:55, Thaddy de Koning wrote: The most recently published build by me takes full advantage of most of the features for ARMV6 EABIHF. Plz advice on how to progress, By never saying that people should build trunk with trunk. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
Which means you shut out the platform. Which is a teaching platform. On 10/23/2014 11:04 AM, Jonas Maebe wrote: On 23/10/14 10:55, Thaddy de Koning wrote: The most recently published build by me takes full advantage of most of the features for ARMV6 EABIHF. Plz advice on how to progress, By never saying that people should build trunk with trunk. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
On 23/10/14 11:00, Thaddy de Koning wrote: At the moment, there is not a good, publicly available, starting compiler other than my unofficial builds. The real starting compiler has never been public AFAIK. The real starting compiler is a cross-compiler. You always have to start using a cross-compiler when building for a platform on which the previous release is not available. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
I know it is a cross- compiler. My builds include a (actually 2) cross-compiler(based on my own builds 2.7.1) The original is NOT a 2.6.X build that is publicly available. That's the point. Where is the dogfood? Where is the starting compiler for Raspian/Debian? Point me at that and I have no complaints. On 10/23/2014 11:10 AM, Jonas Maebe wrote: On 23/10/14 11:00, Thaddy de Koning wrote: At the moment, there is not a good, publicly available, starting compiler other than my unofficial builds. The real starting compiler has never been public AFAIK. The real starting compiler is a cross-compiler. You always have to start using a cross-compiler when building for a platform on which the previous release is not available. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
On 23/10/14 11:09, Thaddy de Koning wrote: On 10/23/2014 11:04 AM, Jonas Maebe wrote: On 23/10/14 10:55, Thaddy de Koning wrote: Plz advice on how to progress, By never saying that people should build trunk with trunk. Which means you shut out the platform. I'm not saying you can't provide any downloads, nor that Debian/Raspbian must remove their custom patched 2.6.4 releases. I'm only saying that you should never encourage people to build trunk with trunk for the reasons that I have explained many times before. Which is a teaching platform. So don't teach them bad practices that will get them into trouble. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
On 23/10/14 11:16, Thaddy de Koning wrote: I know it is a cross- compiler. My builds include a (actually 2) cross-compiler(based on my own builds 2.7.1) The original is NOT a 2.6.X build that is publicly available. That's the point. Where is the dogfood? Where is the starting compiler for Raspian/Debian? Point me at that and I have no complaints. The starting compiler is any official FPC 2.6.4 compiler that can be downloaded from our website. With any of those compilers, you can build both cross and native trunk compiler for any of the targets supported only by trunk. That's how all targets are bootstrapped. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
Not for ARMV6 EABIHF On 10/23/2014 11:23 AM, Jonas Maebe wrote: On 23/10/14 11:16, Thaddy de Koning wrote: I know it is a cross- compiler. My builds include a (actually 2) cross-compiler(based on my own builds 2.7.1) The original is NOT a 2.6.X build that is publicly available. That's the point. Where is the dogfood? Where is the starting compiler for Raspian/Debian? Point me at that and I have no complaints. The starting compiler is any official FPC 2.6.4 compiler that can be downloaded from our website. With any of those compilers, you can build both cross and native trunk compiler for any of the targets supported only by trunk. That's how all targets are bootstrapped. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
Bad practise is the only practise if knowledge about good practise is not available. I am fully prepared to accept you are right. In fact, in my professional settings I would not do otherwise. But this is a special case, for a huge platform, and somebody, somehow, forgot about the license Because the starting compiler for Raspbian is not available.. That's the point: In war ( I am a former tank commander when it was still relevant for an 19 year old) You improvise when resources are not available. I agree with you. Get it? But where's the stuff we can use to do it properly? My stuff works, is based on trunk, but not usable? Ofcourse not. This goes to the core of the project: either one sticks to the rules, or one deviates from it. This is a blatant case of GPL ignorance, since the starting compiler is not made available. And the compiler is GPL'd THAT'S my point. On 10/23/2014 11:16 AM, Jonas Maebe wrote: On 23/10/14 11:09, Thaddy de Koning wrote: On 10/23/2014 11:04 AM, Jonas Maebe wrote: On 23/10/14 10:55, Thaddy de Koning wrote: Plz advice on how to progress, By never saying that people should build trunk with trunk. Which means you shut out the platform. I'm not saying you can't provide any downloads, nor that Debian/Raspbian must remove their custom patched 2.6.4 releases. I'm only saying that you should never encourage people to build trunk with trunk for the reasons that I have explained many times before. Which is a teaching platform. So don't teach them bad practices that will get them into trouble. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
On 23/10/14 11:28, Thaddy de Koning wrote: The starting compiler is any official FPC 2.6.4 compiler that can be downloaded from our website. With any of those compilers, you can build both cross and native trunk compiler for any of the targets supported only by trunk. That's how all targets are bootstrapped. Not for ARMV6 EABIHF That's why I said you have to cross-compile. E.g.: * download FPC 2.6.4 of Linux/i386 * install FPC 2.6.4 for Linux/i386 * install a buildroot for ARM EABI (alternatively: install cross-binutils and copy /lib and /usr/lib from the target system to a folder your local machine) * download the FPC trunk sources * in the FPC trunk directory, do something like make CPU_TARGET=arm OS_TARGET=linux BINUTILSPREFIX=arm-linux-gnueabi- OPT=-dFPC_ARMHF CROSSOPT=-Cparmv6m -XR/path/to/crosssysroot/ other options you need all You may get errors with the above due to missing library search paths (like mentioned earlier in the thread), but no more than when building natively. Again: this is equivalent to the procedure as the one you have to follow to get an AIX compiler or a compiler for any other target only supported by trunk. There are no bootstrap compilers built from secret or specially patched sources, as you seem to suggest in your other reply. Well, the Debian/Raspbian 2.6.4 *native* EABIHF compiler is built from specially patched sources, but those patches are available in the corresponding Debian source package. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
Thaddy de Koning wrote: Not for ARMV6 EABIHF Building for ARMV6+vfpv2 armhf is indeed a bit of a messs. Afaict it's not possible to build a cross compiler that defaults to armv6 ARMHF without modifying the source. With the right flags you should be able to create a cross-compiler that is armhf but defaults to ARMv7 and then with the right flags to that you should be able to build a native armv6 armhf compiler using it but I have never tried this. Since you seem to think we are keeping stuff secret I should say how things were actually bootstrapped for debian/raspbian. The initial armhf port I did (of then-current trunk) was done on an armv7 system. using a debian armel build of 2.6.0 and manually setting -dFPC_ARMHF. This was easier at the time than it is now because iirc debian hadn't yet moved the system libraries to multiarch paths. Once my change was accepted into trunk I then backported the changes to 2.6.0 and packaged them in debian. Later debian armhf packages were simply built using the existing debian packages. I did have to make a small change to get 2.6.2 armhf to build with 2.6.0 armhf. The raspbian packages were based on the debian packages and added a further patch to the source to change the default target to armv6+vfpv2. The intial raspbian packages were built using the debian armhf packages, later raspbian packages were built using previous raspbian packages. Meanwhile over in trunk fpk (iirc) added a patch to make the compiler default to targetting armv6+vfpv2 if the compiler itself was built for armv6. A trunk compiler built to target armhf and running on any other CPU will default to targetting armv7+vfpv3_d16. Someone also added code to make fpc look for libraries in multiarch paths on armel and armhf (despite me having been previously told that we should use fpc.cfg and the fpc maintainers wouldn't do this). You can sometimes get away with using armhf libraries with an armel compiler if you don't care about any C library calls that involve floating point being broken. Certainly enough worked for the threaded tools used in the FPC build process to work. IMO there should be an option to the FPC build to build without linking against C libraries, it's kinda crazy that we have to screw arround with the source to do it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
On 10/23/2014 11:49 AM, Jonas Maebe wrote: On 23/10/14 11:28, Thaddy de Koning wrote: The starting compiler is any official FPC 2.6.4 compiler that can be downloaded from our website. With any of those compilers, you can build both cross and native trunk compiler for any of the targets supported only by trunk. That's how all targets are bootstrapped. Not for ARMV6 EABIHF That's why I said you have to cross-compile. E.g.: * download FPC 2.6.4 of Linux/i386 And for those who are wondering why Jonas is making such a big point out of this: http://bugs.freepascal.org/view.php?id=26930 (Just a bug report from today) We get this kind of bugs, questions and comments all the time. All from people who try to build trunk-with-trunk, while they do not know what they are doing. That must stop. So, please, please, *never* say you can/have to build fpc-trunk with fpc-trunk. (Unless it's the same revision) Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
ok, but can we now please return this thread to the original subject re 2.7.1 (and 2.6.4) for rpi. TIA John On 23 October 2014 13:41, Joost van der Sluis jo...@cnoc.nl wrote: On 10/23/2014 11:49 AM, Jonas Maebe wrote: On 23/10/14 11:28, Thaddy de Koning wrote: The starting compiler is any official FPC 2.6.4 compiler that can be downloaded from our website. With any of those compilers, you can build both cross and native trunk compiler for any of the targets supported only by trunk. That's how all targets are bootstrapped. Not for ARMV6 EABIHF That's why I said you have to cross-compile. E.g.: * download FPC 2.6.4 of Linux/i386 And for those who are wondering why Jonas is making such a big point out of this: http://bugs.freepascal.org/view.php?id=26930 (Just a bug report from today) We get this kind of bugs, questions and comments all the time. All from people who try to build trunk-with-trunk, while they do not know what they are doing. That must stop. So, please, please, *never* say you can/have to build fpc-trunk with fpc-trunk. (Unless it's the same revision) Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
With this in mind, how is one supposed to go about implementing a brand new target? Should I build a compiler from modified release branch, then use that to compile the modified trunk? On 10/23/2014 5:04 AM, Jonas Maebe wrote: By never saying that people should build trunk with trunk. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
In our previous episode, Thaddy de Koning said: Bad practise is the only practise if knowledge about good practise is not available. Should I change cursive to bold here then? http://www.stack.nl/~marcov/buildfaq/#toc-Section-2.2 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
On 23/10/14 16:21, Vsevolod Alekseyev wrote: With this in mind, how is one supposed to go about implementing a brand new target? Should I build a compiler from modified release branch, then use that to compile the modified trunk? You build a cross-compiler for your brand new target from the modified trunk using a release for an already supported target, as explained in http://lists.freepascal.org/pipermail/fpc-devel/2014-October/034634.html Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
If you follow the steps in that post, you'll get the following: makefile:197: *** The Makefile doesn't support target i386-winphonesim, please r un fpcmake first. Stop. If you run fpcmake -Tall -w first, you'll get the same. Looks like the first step should be rebuilding fpcmake itself with the new target in mind... On 10/23/2014 10:29 AM, Jonas Maebe wrote: On 23/10/14 16:21, Vsevolod Alekseyev wrote: With this in mind, how is one supposed to go about implementing a brand new target? Should I build a compiler from modified release branch, then use that to compile the modified trunk? You build a cross-compiler for your brand new target from the modified trunk using a release for an already supported target, as explained in http://lists.freepascal.org/pipermail/fpc-devel/2014-October/034634.html Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
On 23/10/14 17:06, Vsevolod Alekseyev wrote: If you follow the steps in that post, you'll get the following: makefile:197: *** The Makefile doesn't support target i386-winphonesim, please r un fpcmake first. Stop. If you run fpcmake -Tall -w first, you'll get the same. Looks like the first step should be rebuilding fpcmake itself with the new target in mind... Yes, indeed. But that's the same regardless of whether you use a trunk compiler or a compiler from latest release to build everything. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
There's no separate makefile for fpcmake alone, is there? On 10/23/2014 11:12 AM, Jonas Maebe wrote: On 23/10/14 17:06, Vsevolod Alekseyev wrote: If you follow the steps in that post, you'll get the following: makefile:197: *** The Makefile doesn't support target i386-winphonesim, please r un fpcmake first. Stop. If you run fpcmake -Tall -w first, you'll get the same. Looks like the first step should be rebuilding fpcmake itself with the new target in mind... Yes, indeed. But that's the same regardless of whether you use a trunk compiler or a compiler from latest release to build everything. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
On 10/23/2014 08:41 AM, Joost van der Sluis wrote: On 10/23/2014 11:49 AM, Jonas Maebe wrote: On 23/10/14 11:28, Thaddy de Koning wrote: The starting compiler is any official FPC 2.6.4 compiler that can be downloaded from our website. With any of those compilers, you can build both cross and native trunk compiler for any of the targets supported only by trunk. That's how all targets are bootstrapped. Not for ARMV6 EABIHF That's why I said you have to cross-compile. E.g.: * download FPC 2.6.4 of Linux/i386 And for those who are wondering why Jonas is making such a big point out of this: http://bugs.freepascal.org/view.php?id=26930 (Just a bug report from today) We get this kind of bugs, questions and comments all the time. All from people who try to build trunk-with-trunk, while they do not know what they are doing. That must stop. So, please, please, *never* say you can/have to build fpc-trunk with fpc-trunk. (Unless it's the same revision) Joost. This thread has been *very* educational so thanks to all who participated. I've spent a bit of time during the past 7 years trying to figure out how to simplify things by avoiding cross-compiling. I'll start another thread about this but I think there is a way to simplify cross-compiling. Levinux is a small Qemu download for x86 PC (Windows, OS X, Linux) that provides a small Linux VM. I'd like to see something similar but with Debian and all the files and tools needed to cross-compile FPC. Please hold your comments until there is a new thread (feel free to start that). Thanks! http://mikelev.in/ux/ http://www.turbocontrol.com/devoptions.htm ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpcmkcfg invocation for two versions (linux)
Gennadiy Poryev wrote: thank you, but my question was more about where to put fpc.cfg so that both versions can use it properly, or, if that is not possible, where to stuff different fpc.cfg's for the same purpose? and what would be the basepath in either case? execute ppx64 -vut the last lines of the output list the patch searched for fpc.cfg In my case [0.004] Configfile search: /home/marc/.fpc.cfg [0.004] Configfile search: /home/marc/etc/fpc.cfg [0.004] Configfile search: /etc/fpc.cfg I also vaguely recall that the dir of the compiler is searched too, but isn't listed here (it might be a windows only thing or something from the past) Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
In our previous episode, Vsevolod Alekseyev said: There's no separate makefile for fpcmake alone, is there? No. There are more such cases, and while there are tricks for advanced users, like with the starting compiler version, I suggest you stick to the official requirement of having the full release installed. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dumping the syntax tree
On second look, no, the -vp tree is not sufficient. It doesn't have datatype definitions, doesn't have interface definitions... On 10/22/2014 4:44 AM, Nikolay Nikolov wrote: On 10/22/2014 12:23 AM, Vsevolod Alekseyev wrote: Hi all, I wonder where in the FPC compilation flow would be a good spot to dump the parsed syntax tree of a source? Here's why I'm asking. For a while now, I've been struggling to adapt a bunch of Pascal code to various mobile platforms. It's been painful. The code itself is pretty conservative feature-wise, almost KR C-like (except sets and ansistrings). I wonder if I could slap together a quick and dirty Pascal-to-C converter just for this codebase to work, but I'd rather reuse the existing parsing logic. So if anyone could point me at a spot in the FPC source where the source tree is more or less ready, that's be nice. Thanks in advance. The compiler already supports dumping the parse tree when you use the -vp option. But it's more intended for debugging the compiler - I don't know if it'll work for you. Nikolay ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dumping the syntax tree
On 23.10.2014 г. 18:59, Vsevolod Alekseyev wrote: On second look, no, the -vp tree is not sufficient. It doesn't have datatype definitions, doesn't have interface definitions... True. I guess, you can try to use ppudump in order to dump these definitions. It'll only work for units though, but I guess it shouldn't be too hard to make the compiler output ppu files for programs as well. Nikolay On 10/22/2014 4:44 AM, Nikolay Nikolov wrote: On 10/22/2014 12:23 AM, Vsevolod Alekseyev wrote: Hi all, I wonder where in the FPC compilation flow would be a good spot to dump the parsed syntax tree of a source? Here's why I'm asking. For a while now, I've been struggling to adapt a bunch of Pascal code to various mobile platforms. It's been painful. The code itself is pretty conservative feature-wise, almost KR C-like (except sets and ansistrings). I wonder if I could slap together a quick and dirty Pascal-to-C converter just for this codebase to work, but I'd rather reuse the existing parsing logic. So if anyone could point me at a spot in the FPC source where the source tree is more or less ready, that's be nice. Thanks in advance. The compiler already supports dumping the parse tree when you use the -vp option. But it's more intended for debugging the compiler - I don't know if it'll work for you. Nikolay ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dumping the syntax tree
I don't see local variable definitions there, either... On 10/23/2014 12:15 PM, Nikolay Nikolov wrote: On 23.10.2014 г. 18:59, Vsevolod Alekseyev wrote: On second look, no, the -vp tree is not sufficient. It doesn't have datatype definitions, doesn't have interface definitions... True. I guess, you can try to use ppudump in order to dump these definitions. It'll only work for units though, but I guess it shouldn't be too hard to make the compiler output ppu files for programs as well. Nikolay On 10/22/2014 4:44 AM, Nikolay Nikolov wrote: On 10/22/2014 12:23 AM, Vsevolod Alekseyev wrote: Hi all, I wonder where in the FPC compilation flow would be a good spot to dump the parsed syntax tree of a source? Here's why I'm asking. For a while now, I've been struggling to adapt a bunch of Pascal code to various mobile platforms. It's been painful. The code itself is pretty conservative feature-wise, almost KR C-like (except sets and ansistrings). I wonder if I could slap together a quick and dirty Pascal-to-C converter just for this codebase to work, but I'd rather reuse the existing parsing logic. So if anyone could point me at a spot in the FPC source where the source tree is more or less ready, that's be nice. Thanks in advance. The compiler already supports dumping the parse tree when you use the -vp option. But it's more intended for debugging the compiler - I don't know if it'll work for you. Nikolay ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dumping the syntax tree
Lazarus has a Pascal tokenizer unit under components\mpaslex\mpaslex.pp. It seems old and doesn't look like it supports the full FPC syntax, but it might be a starting point since most likely you can convert the code to C++ with GNU GCC extensions (nested functions, etc) straightforward. On Thu, Oct 23, 2014 at 6:25 PM, Vsevolod Alekseyev se...@sprynet.com wrote: I don't see local variable definitions there, either... On 10/23/2014 12:15 PM, Nikolay Nikolov wrote: On 23.10.2014 г. 18:59, Vsevolod Alekseyev wrote: On second look, no, the -vp tree is not sufficient. It doesn't have datatype definitions, doesn't have interface definitions... True. I guess, you can try to use ppudump in order to dump these definitions. It'll only work for units though, but I guess it shouldn't be too hard to make the compiler output ppu files for programs as well. Nikolay On 10/22/2014 4:44 AM, Nikolay Nikolov wrote: On 10/22/2014 12:23 AM, Vsevolod Alekseyev wrote: Hi all, I wonder where in the FPC compilation flow would be a good spot to dump the parsed syntax tree of a source? Here's why I'm asking. For a while now, I've been struggling to adapt a bunch of Pascal code to various mobile platforms. It's been painful. The code itself is pretty conservative feature-wise, almost KR C-like (except sets and ansistrings). I wonder if I could slap together a quick and dirty Pascal-to-C converter just for this codebase to work, but I'd rather reuse the existing parsing logic. So if anyone could point me at a spot in the FPC source where the source tree is more or less ready, that's be nice. Thanks in advance. The compiler already supports dumping the parse tree when you use the -vp option. But it's more intended for debugging the compiler - I don't know if it'll work for you. Nikolay ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Code generated for the embedded arm port for lpc1768 (armv7m)
Hello,
I am trying to get the embedded version of fpc for arm to work.
Currently i try it for the lpc1768 from NXP using the lpcxpresso board.
The example compiles, but doesn't run on the target...
I created a simple example and it seems that the code it generates is NOT
thumb2 code.
I disassembled the elf-file generated by fpc using arm-none-eabi-objdump -S
I also disassembled it using the debugger arm-none-eabi-gdb
Here is a fragment of the code from both:
From objdump:
01c4 FPC_INITIALIZEUNITS:
1c4: e92d4070push{r4, r5, r6, lr}
1c8: ebf5bl 1a4 SYSTEM_$$_FPC_CPUINIT
1cc: e59f006cldr r0, [pc, #108] ; 240 FPC_INITIALIZEUNITS+0x7c
1d0: e5904000ldr r4, [r0]
1d4: e3a05001mov r5, #1
1d8: e1540005cmp r4, r5
1dc: ba0fblt 220 FPC_INITIALIZEUNITS+0x5c
From gdb
0x01c4 fpc_initializeunits+0:70 40 eors
r0, r6
0x01c6 fpc_initializeunits+2:2d e9 f5 ff
stmdb sp!, {r0, r2, r4, r5, r6, r7, r8, r9, r10, r11, r12, sp, lr, pc}
= 0x01ca fpc_initializeunits+6: ff eb 6c 00
; UNDEFINED instruction: 0xebff006c
0x01ce fpc_initializeunits+10: 9f e5 b.n
0xfd10
0x01d0 fpc_initializeunits+12: 00 40 ands
r0, r0
0x01d2 fpc_initializeunits+14: 90 e5 b.n
0xfcf6
0x01d4 fpc_initializeunits+16: 01 50 str
r1, [r0, r0]
0x01d6 fpc_initializeunits+18: a0 e3 b.n
0x91a
0x01d8 fpc_initializeunits+20: 05 00 movs
r5, r0
0x01da fpc_initializeunits+22: 54 e1 b.n
0x486
0x01dc fpc_initializeunits+24: 0f 00 movs
r7, r1
Note how the interpretation of the code is different, as is the length of most
instructions.
It looks to me as if the code in the elf-file are (mostly) 32-bit values, while
the debugger does interpret thee code as thumb2 (i think).
In the Makefile in rtl/embedded I find:
ifeq ($(SUBARCH),armv7m)
CPU_UNITS=lm3fury lm3tempest stm32f10x_ld stm32f10x_md stm32f10x_hd
stm32f10x_xl stm32f10x_conn stm32f10x_cl lpc13xx lpc1768 lm4f120 xmc4500
cortexm3 cortexm4 # thumb2_bare
endif
So that suggest (via the comment) that fpc can do thumb2 code, which it should
for cortexm3.
My PC is debian/jessie/64bit: Free Pascal Compiler version 2.6.4+dfsg-3
[2014/07/12] for x86_64
I got the sourcecode for the port from svn as described on the website.
To create the port I do:
make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded
CPU_TARGET=arm SUBARCH=armv7m BINUTILSPREFIX=arm-none-eabi-
For the binutils I use the (current) stuff for the lpc1768 from NXP:
lpcxpresso_7.4.0_229
To create a program I do:
ppcrossarm -Ch1024 -Cs1024 -Tembedded -Parm -Cparmv7m -XParm-none-eabi-
-Wplpc1768 -vu prog.p
Is there anybody that did get this port to work?
Thanks in advance,
Sietse
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Code generated for the embedded arm port for lpc1768 (armv7m)
Are you sure those are the precise steps you took? Because that should
work as you expected it unless you have a broken binutils version. It's
normally very quick to complain about incompatible ARM versions
Try to disassemble the objects in the source directory at
rtl/units/arm-embedded
Those should largely contain variable length thumb2 code.
Den 23-10-2014 20:15, Sietse Achterop skrev:
Hello,
I am trying to get the embedded version of fpc for arm to work.
Currently i try it for the lpc1768 from NXP using the lpcxpresso board.
The example compiles, but doesn't run on the target...
I created a simple example and it seems that the code it generates is
NOT thumb2 code.
I disassembled the elf-file generated by fpc using
arm-none-eabi-objdump -S
I also disassembled it using the debugger arm-none-eabi-gdb
Here is a fragment of the code from both:
From objdump:
01c4 FPC_INITIALIZEUNITS:
1c4:e92d4070 push{r4, r5, r6, lr}
1c8:ebf5 bl1a4 SYSTEM_$$_FPC_CPUINIT
1cc:e59f006c ldrr0, [pc, #108]; 240
FPC_INITIALIZEUNITS+0x7c
1d0:e5904000 ldrr4, [r0]
1d4:e3a05001 movr5, #1
1d8:e1540005 cmpr4, r5
1dc:ba0f blt220 FPC_INITIALIZEUNITS+0x5c
From gdb
0x01c4 fpc_initializeunits+0:70 40 eors
r0, r6
0x01c6 fpc_initializeunits+2:2d e9 f5 ff
stmdbsp!, {r0, r2, r4, r5, r6, r7, r8, r9, r10, r11, r12, sp, lr, pc}
= 0x01ca fpc_initializeunits+6:ff eb 6c
00 ; UNDEFINED instruction: 0xebff006c
0x01ce fpc_initializeunits+10:9f e5
b.n 0xfd10
0x01d0 fpc_initializeunits+12:00 40
ands r0, r0
0x01d2 fpc_initializeunits+14:90 e5
b.n 0xfcf6
0x01d4 fpc_initializeunits+16:01 50
str r1, [r0, r0]
0x01d6 fpc_initializeunits+18:a0 e3
b.n 0x91a
0x01d8 fpc_initializeunits+20:05 00
movs r5, r0
0x01da fpc_initializeunits+22:54 e1
b.n 0x486
0x01dc fpc_initializeunits+24:0f 00
movs r7, r1
Note how the interpretation of the code is different, as is the length
of most instructions.
It looks to me as if the code in the elf-file are (mostly) 32-bit
values, while the debugger does interpret thee code as thumb2 (i think).
In the Makefile in rtl/embedded I find:
ifeq ($(SUBARCH),armv7m)
CPU_UNITS=lm3fury lm3tempest stm32f10x_ld stm32f10x_md
stm32f10x_hd stm32f10x_xl stm32f10x_conn stm32f10x_cl lpc13xx lpc1768
lm4f120 xmc4500 cortexm3 cortexm4 # thumb2_bare
endif
So that suggest (via the comment) that fpc can do thumb2 code, which
it should for cortexm3.
My PC is debian/jessie/64bit: Free Pascal Compiler version
2.6.4+dfsg-3 [2014/07/12] for x86_64
I got the sourcecode for the port from svn as described on the website.
To create the port I do:
make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded
CPU_TARGET=arm SUBARCH=armv7m BINUTILSPREFIX=arm-none-eabi-
For the binutils I use the (current) stuff for the lpc1768 from NXP:
lpcxpresso_7.4.0_229
To create a program I do:
ppcrossarm -Ch1024 -Cs1024 -Tembedded -Parm -Cparmv7m
-XParm-none-eabi- -Wplpc1768 -vu prog.p
Is there anybody that did get this port to work?
Thanks in advance,
Sietse
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Code generated for the embedded arm port for lpc1768 (armv7m)
I remember seeing the problem that gdb does not correctly disassemble
code...
Please do a
arm-none-eabi-readelf -A xxx.elf
you should see:
File Attributes
Tag_CPU_name: 7-M
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Microcontroller
Tag_THUMB_ISA_use: *Thumb-2*
Compiling, linking and running is fine for me, difference in setup is
that I use another processor (stm32f407) and that I used trunk sources
to compile the crosscompiler.
But as Jeppe already mentioned, this all should have worked fine with
2.6.4 version too.
And your commandline you used for both creating the crosscompiler /
build the program is exactly the same I use.
Michael
Am 23.10.14 um 20:15 schrieb Sietse Achterop:
Hello,
I am trying to get the embedded version of fpc for arm to work.
Currently i try it for the lpc1768 from NXP using the lpcxpresso board.
The example compiles, but doesn't run on the target...
I created a simple example and it seems that the code it generates is
NOT thumb2 code.
I disassembled the elf-file generated by fpc using
arm-none-eabi-objdump -S
I also disassembled it using the debugger arm-none-eabi-gdb
Here is a fragment of the code from both:
From objdump:
01c4 FPC_INITIALIZEUNITS:
1c4:e92d4070 push{r4, r5, r6, lr}
1c8:ebf5 bl1a4 SYSTEM_$$_FPC_CPUINIT
1cc:e59f006c ldrr0, [pc, #108]; 240
FPC_INITIALIZEUNITS+0x7c
1d0:e5904000 ldrr4, [r0]
1d4:e3a05001 movr5, #1
1d8:e1540005 cmpr4, r5
1dc:ba0f blt220 FPC_INITIALIZEUNITS+0x5c
From gdb
0x01c4 fpc_initializeunits+0:70 40 eors
r0, r6
0x01c6 fpc_initializeunits+2:2d e9 f5 ff
stmdbsp!, {r0, r2, r4, r5, r6, r7, r8, r9, r10, r11, r12, sp, lr, pc}
= 0x01ca fpc_initializeunits+6:ff eb 6c
00 ; UNDEFINED instruction: 0xebff006c
0x01ce fpc_initializeunits+10:9f e5
b.n 0xfd10
0x01d0 fpc_initializeunits+12:00 40
ands r0, r0
0x01d2 fpc_initializeunits+14:90 e5
b.n 0xfcf6
0x01d4 fpc_initializeunits+16:01 50
str r1, [r0, r0]
0x01d6 fpc_initializeunits+18:a0 e3
b.n 0x91a
0x01d8 fpc_initializeunits+20:05 00
movs r5, r0
0x01da fpc_initializeunits+22:54 e1
b.n 0x486
0x01dc fpc_initializeunits+24:0f 00
movs r7, r1
Note how the interpretation of the code is different, as is the length
of most instructions.
It looks to me as if the code in the elf-file are (mostly) 32-bit
values, while the debugger does interpret thee code as thumb2 (i think).
In the Makefile in rtl/embedded I find:
ifeq ($(SUBARCH),armv7m)
CPU_UNITS=lm3fury lm3tempest stm32f10x_ld stm32f10x_md
stm32f10x_hd stm32f10x_xl stm32f10x_conn stm32f10x_cl lpc13xx lpc1768
lm4f120 xmc4500 cortexm3 cortexm4 # thumb2_bare
endif
So that suggest (via the comment) that fpc can do thumb2 code, which
it should for cortexm3.
My PC is debian/jessie/64bit: Free Pascal Compiler version
2.6.4+dfsg-3 [2014/07/12] for x86_64
I got the sourcecode for the port from svn as described on the website.
To create the port I do:
make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded
CPU_TARGET=arm SUBARCH=armv7m BINUTILSPREFIX=arm-none-eabi-
For the binutils I use the (current) stuff for the lpc1768 from NXP:
lpcxpresso_7.4.0_229
To create a program I do:
ppcrossarm -Ch1024 -Cs1024 -Tembedded -Parm -Cparmv7m
-XParm-none-eabi- -Wplpc1768 -vu prog.p
Is there anybody that did get this port to work?
Thanks in advance,
Sietse
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Code generated for the embedded arm port for lpc1768 (armv7m)
One more thing:
Did you try to run the code directly on the device after uploading it or
did you use a debugger to start the program?
When I remember correcly all LPCxxx devices need a magic checksum so
that they are started on the device. The creation of this checksum is in
trunk, but I am pretty sure that it is not in release 2.6.4.
Michael
Am 23.10.14 um 20:52 schrieb Michael Ring:
I remember seeing the problem that gdb does not correctly disassemble
code...
Please do a
arm-none-eabi-readelf -A xxx.elf
you should see:
File Attributes
Tag_CPU_name: 7-M
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Microcontroller
Tag_THUMB_ISA_use: *Thumb-2*
Compiling, linking and running is fine for me, difference in setup is
that I use another processor (stm32f407) and that I used trunk sources
to compile the crosscompiler.
But as Jeppe already mentioned, this all should have worked fine with
2.6.4 version too.
And your commandline you used for both creating the crosscompiler /
build the program is exactly the same I use.
Michael
Am 23.10.14 um 20:15 schrieb Sietse Achterop:
Hello,
I am trying to get the embedded version of fpc for arm to work.
Currently i try it for the lpc1768 from NXP using the lpcxpresso board.
The example compiles, but doesn't run on the target...
I created a simple example and it seems that the code it generates is
NOT thumb2 code.
I disassembled the elf-file generated by fpc using
arm-none-eabi-objdump -S
I also disassembled it using the debugger arm-none-eabi-gdb
Here is a fragment of the code from both:
From objdump:
01c4 FPC_INITIALIZEUNITS:
1c4:e92d4070 push{r4, r5, r6, lr}
1c8:ebf5 bl1a4 SYSTEM_$$_FPC_CPUINIT
1cc:e59f006c ldrr0, [pc, #108]; 240
FPC_INITIALIZEUNITS+0x7c
1d0:e5904000 ldrr4, [r0]
1d4:e3a05001 movr5, #1
1d8:e1540005 cmpr4, r5
1dc:ba0f blt220 FPC_INITIALIZEUNITS+0x5c
From gdb
0x01c4 fpc_initializeunits+0:70 40 eors
r0, r6
0x01c6 fpc_initializeunits+2:2d e9 f5 ff
stmdbsp!, {r0, r2, r4, r5, r6, r7, r8, r9, r10, r11, r12, sp, lr,
pc}
= 0x01ca fpc_initializeunits+6:ff eb 6c
00 ; UNDEFINED instruction: 0xebff006c
0x01ce fpc_initializeunits+10:9f e5
b.n 0xfd10
0x01d0 fpc_initializeunits+12:00 40
ands r0, r0
0x01d2 fpc_initializeunits+14:90 e5
b.n 0xfcf6
0x01d4 fpc_initializeunits+16:01 50
str r1, [r0, r0]
0x01d6 fpc_initializeunits+18:a0 e3
b.n 0x91a
0x01d8 fpc_initializeunits+20:05 00
movs r5, r0
0x01da fpc_initializeunits+22:54 e1
b.n 0x486
0x01dc fpc_initializeunits+24:0f 00
movs r7, r1
Note how the interpretation of the code is different, as is the
length of most instructions.
It looks to me as if the code in the elf-file are (mostly) 32-bit
values, while the debugger does interpret thee code as thumb2 (i think).
In the Makefile in rtl/embedded I find:
ifeq ($(SUBARCH),armv7m)
CPU_UNITS=lm3fury lm3tempest stm32f10x_ld stm32f10x_md
stm32f10x_hd stm32f10x_xl stm32f10x_conn stm32f10x_cl lpc13xx lpc1768
lm4f120 xmc4500 cortexm3 cortexm4 # thumb2_bare
endif
So that suggest (via the comment) that fpc can do thumb2 code, which
it should for cortexm3.
My PC is debian/jessie/64bit: Free Pascal Compiler version
2.6.4+dfsg-3 [2014/07/12] for x86_64
I got the sourcecode for the port from svn as described on the website.
To create the port I do:
make clean buildbase installbase CROSSINSTALL=1
OS_TARGET=embedded CPU_TARGET=arm SUBARCH=armv7m
BINUTILSPREFIX=arm-none-eabi-
For the binutils I use the (current) stuff for the lpc1768 from NXP:
lpcxpresso_7.4.0_229
To create a program I do:
ppcrossarm -Ch1024 -Cs1024 -Tembedded -Parm -Cparmv7m
-XParm-none-eabi- -Wplpc1768 -vu prog.p
Is there anybody that did get this port to work?
Thanks in advance,
Sietse
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Code generated for the embedded arm port for lpc1768 (armv7m)
On 10/23/2014 08:38 PM, Jeppe Græsdal Johansen wrote: Are you sure those are the precise steps you took? Because that should work as you expected it unless you have a broken binutils version. It's normally very quick to complain about incompatible ARM versions Try to disassemble the objects in the source directory at rtl/units/arm-embedded Those should largely contain variable length thumb2 code. Hello, thanks for the reply. My program code is ok, and also lpc1768.o and the cortexm3_start code is ok. But code from system.o is wrong. And thanks to Michael Ring I now can be more consise: arm-none-eabi-readelf -A lpc1768.o Attribute Section: aeabi File Attributes Tag_CPU_name: 7-M Tag_CPU_arch: v7 Tag_CPU_arch_profile: Microcontroller Tag_THUMB_ISA_use: Thumb-2 arm-none-eabi-readelf -A system.o Attribute Section: aeabi File Attributes Tag_CPU_arch: v5TE Tag_ARM_ISA_use: Yes Tag_THUMB_ISA_use: Thumb-1 So why is system.o generated in the wrong version? I think that I did everything as I said. I will do the compiler starting from scratch again, just to be sure. I now know where to look for. Sietse ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Code generated for the embedded arm port for lpc1768 (armv7m)
This smells like some system.o left over from an old build or from an incorrect setting in fpc.cfg. Please use the switch -vu when you compile your program to find out where this file is in your filesystem. If you do not get the correct path then please add the parameter -sh to your commandline. This does create a link script, the good thing is that you can now do: cat link.res SEARCH_DIR(/usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/) SEARCH_DIR(/usr/local/lib/fpc/2.7.1/units/arm-embedded/) SEARCH_DIR(/usr/local/lib/fpc/2.7.1/) INPUT ( peephole.o /usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/system.o /usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/objpas.o /usr/local/lib/fpc/2.7.1/units/arm-embedded/rtl/stm32f40x.o ) and you can see where system.o comes from. Michael Am 23.10.14 um 21:08 schrieb Sietse Achterop: On 10/23/2014 08:38 PM, Jeppe Græsdal Johansen wrote: Are you sure those are the precise steps you took? Because that should work as you expected it unless you have a broken binutils version. It's normally very quick to complain about incompatible ARM versions Try to disassemble the objects in the source directory at rtl/units/arm-embedded Those should largely contain variable length thumb2 code. Hello, thanks for the reply. My program code is ok, and also lpc1768.o and the cortexm3_start code is ok. But code from system.o is wrong. And thanks to Michael Ring I now can be more consise: arm-none-eabi-readelf -A lpc1768.o Attribute Section: aeabi File Attributes Tag_CPU_name: 7-M Tag_CPU_arch: v7 Tag_CPU_arch_profile: Microcontroller Tag_THUMB_ISA_use: Thumb-2 arm-none-eabi-readelf -A system.o Attribute Section: aeabi File Attributes Tag_CPU_arch: v5TE Tag_ARM_ISA_use: Yes Tag_THUMB_ISA_use: Thumb-1 So why is system.o generated in the wrong version? I think that I did everything as I said. I will do the compiler starting from scratch again, just to be sure. I now know where to look for. Sietse ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Code generated for the embedded arm port for lpc1768 (armv7m)
On 10/23/2014 09:16 PM, Michael Ring wrote: This smells like some system.o left over from an old build or from an incorrect setting in fpc.cfg. Please use the switch -vu when you compile your program to find out where this file is in your filesystem. I redid the creation of the compiler, and all is well now! I still can't remember where i went wrong before, but all generated code is thumb-2 now! Thanks for the quick help! Sietse ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dumping the syntax tree
You had better use the fcl-passrc units. They dump a complete syntax tree. It is used to generate (a currently limited version of) javascript, and used to create documentation. so it should be usable to generate C code... The test program re-dumps a pascal program. Presumably you can adapt that to generate C. Michael. On Thu, 23 Oct 2014, Kostas Michalopoulos wrote: Lazarus has a Pascal tokenizer unit under components\mpaslex\mpaslex.pp. It seems old and doesn't look like it supports the full FPC syntax, but it might be a starting point since most likely you can convert the code to C++ with GNU GCC extensions (nested functions, etc) straightforward. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dumping the syntax tree
What test program, please? Where? On 10/23/2014 4:12 PM, Michael Van Canneyt wrote: You had better use the fcl-passrc units. They dump a complete syntax tree. It is used to generate (a currently limited version of) javascript, and used to create documentation. so it should be usable to generate C code... The test program re-dumps a pascal program. Presumably you can adapt that to generate C. Michael. On Thu, 23 Oct 2014, Kostas Michalopoulos wrote: Lazarus has a Pascal tokenizer unit under components\mpaslex\mpaslex.pp. It seems old and doesn't look like it supports the full FPC syntax, but it might be a starting point since most likely you can convert the code to C++ with GNU GCC extensions (nested functions, etc) straightforward. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dumping the syntax tree
See the FPC sources: packages/fcl-passrc/examples/test_parser.pp Michael. On Thu, 23 Oct 2014, Vsevolod Alekseyev wrote: What test program, please? Where? On 10/23/2014 4:12 PM, Michael Van Canneyt wrote: You had better use the fcl-passrc units. They dump a complete syntax tree. It is used to generate (a currently limited version of) javascript, and used to create documentation. so it should be usable to generate C code... The test program re-dumps a pascal program. Presumably you can adapt that to generate C. Michael. On Thu, 23 Oct 2014, Kostas Michalopoulos wrote: Lazarus has a Pascal tokenizer unit under components\mpaslex\mpaslex.pp. It seems old and doesn't look like it supports the full FPC syntax, but it might be a starting point since most likely you can convert the code to C++ with GNU GCC extensions (nested functions, etc) straightforward. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
On 23/10/14 17:16, Vsevolod Alekseyev wrote: There's no separate makefile for fpcmake alone, is there? It used to be as simple as going into utils/fpcm and performing a make all, but with the new FPC-based build system I think that is unfortunately no longer possible. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building 2.7.1 on current Raspbian fails
On 23/10/14 17:43, Marco van de Voort wrote: In our previous episode, Vsevolod Alekseyev said: There's no separate makefile for fpcmake alone, is there? No. There are more such cases, and while there are tricks for advanced users, like with the starting compiler version, I suggest you stick to the official requirement of having the full release installed. The question here was about implementing a new target in FPC and then regenerating the makefiles for that new target. This requires an fpcmake built from the trunk sources. That's not really the same as what the original thread was about though (which was compiling FPC trunk for a target that was not available in the previous release, but which has already been fully implemented and integrated in trunk). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
