- This topic has 8 replies, 2 voices, and was last updated 3 years, 1 month ago by
.
-
Posts
-
Hi,
I’m trying to cross compile a Raspberry PI project that uses boost using Visual Studio 2019 and MSBuild. While the project compiles correct but slow when I don’t use precompiled headers it immediately stops compiling when I add the use of precompiled headers. In my event viewer I can see that ..\sysgcc\raspberry\bin\..\libexec\gcc\arm-linux-gnueabihf\8\cc1plus.exe crashes with exception code 0xc0000005. I already did the editbin /LARGEADDRESSAWARE and editbin /STACK things but it doesn’t help. My guess would be that cc1plus.exe is still only supporting up to 128 MByte for a precompiled header file due to the definition of pch_VA_max_size. Is there a chance to get a cc1plus.exe that supports bigger precompiled header files?
Thanks and best regards,
Johannes
Hi,
This likely happens because our Raspberry Pi toolchain is built for a 32-bit Windows environment. You can try working around it by building your own 64-bit cross-toolchain from the same sources (see Debian instructions for building toolchains). We will also consider shipping building our next Raspberry Pi toolchain for the 64-bit Windows platform.
Another option would be to try reducing the size of the precompiled header file by removing some of the headers from it.
Hi,
thanks for your answer.
I already tried to reduce the size but as soon as you include <boost/asio.hpp> the pch file grows above 128 MBytes. At the moment I don’t think my problem is related to 32-bit as now I don’t see the “out of memory problem” anymore, which I had at the beginning when memory allocation of cc1plus.exe grew beyond 2 GB and which could be solved following this link https://www.intel.com/content/www/us/en/support/programmable/articles/000086946.html . Now I can watch in Task-Manager that cc1plus.exe memory can go above the 2 GB limit and also creating the pch file now seems works correct and it has a final size of 220 MBytes.
The problem now is when compiling other files and using this pch file as there seems to be a limit of 128 MByte for loading pch files in cc1plus.exe. That seems to be related to a fixed definition of “static const size_t pch_VA_max_size = 128 * 1024 * 1024” in host-mingw32.c. My current idea would be to compile my own version of cc1plus.exe with an increased define or a dynamic allocation according to the actual size of the pch file and replace it in the current toolchain but so far I didn’t find good starting points how to do this. Also there’s some discussion in the internet about this hard coded limit and normally this should already be solved now for a while.
Can you please tell me, which version of host-mingw32.c you are using for the toolchain and what the current size limit for a pch file is according to this file?
Thanks and best regards,
Johannes
Hi,
host-mingw32.c is a part of the gcc source package. You can obtain it by running “sudo apt source gcc-<version>” on your Raspberry Pi, and then running “debian/rules build” to apply all patches. That said, it requires a few other non-trivial steps, and usually takes multiple hours and retries to get working.
You might be able to hotpatch it by locating the uses of pch_VA_max_size in the disassembly, and patching it directly. We can also rebuild the toolchain for you with a larger value of pch_VA_max_size, however we would have to charge 1/2 hours at our consulting rate for that, and we would not guarantee that it will solve the problem.
Hi,
thanks again. I also already thought about patching the binary but unfortunately I’m not experienced in decompiling and finding the right byte positions to be patched and I don’t know the appropriate tools. But I hope that sooner or later a fixed cc1plus.exe will be part of the toolchin as this seems to be fixed already for some time now in later versions of GCC. And if a 64 Bit toolchain becomes available this should also be no problem anymore – hopefully 😉
Best regards,
Johannes
Good to know it works. We usually want to minimize the changes to the GCC sources when building our toolchains, because it often has unforeseen side effects (e.g. increasing the size of one buffer could prevent something else from being allocated).
The difficulty of patching would depend on how many assembler instructions would be affected by the change, and how difficult would it be to locate them. From a very brief look into the source, it looked like it would only affect a couple of instructions near public API calls, so it’s easy to find them.
Either way, feel free to share the bytes you changed in the executable, so that other users could replicate it if they run into anything similar before we release a 64-bit toolchain.
You are right – here’s what I changed. I found three positions where I changed 0x08000000 (=128 MByte) to 0x20000000 (=512 MByte). As we’re using little endian it’s the last byte which has to be changed:
position old value => new value 00DBF080 81 7D 08 00 00 00 08 76 => 81 7D 08 00 00 00 20 76 00DBF0A0 C7 44 24 04 00 00 00 08 => C7 44 24 04 00 00 00 20 00DBF148 0C 00 00 00 08 76 0A B8 => 0C 00 00 00 20 76 0A B8
- You must be logged in to reply to this topic.