-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fails to build under x86 (32bit): Excessive memory usage #78
Comments
The failure above is unimplemented support for |
Tested with both hello_world and local tests, didn't run the full run-pass suite |
Thanks, core built with c1d4b60 successfully now. It falls over on a subsequent crate though:
|
Above failure fixed in 2315092, current blocker is casting i128/u128 to f32 |
Confirmed. Thanks
Also confirmed thanks.
|
The i128 support should now be complete enough to build rustc, but cargo build is crashing due to an unknown codegen error. |
Codegen issue isolated to a mismatch between mrustc's calculated object size and gcc's calculation. |
I've just tested with f4483c0. It gets further along, but fails with
|
Bad i128 code fixed, but rustc isn't running correctly due to (probably) bad codegen on gcc's part (leading to a x87 FPU stack overflow). This may just be a local gcc bug (I'm testing with |
Thanks. I've checked here with GCC 5.5 and it failed too.
Valgrind says:
I can upload |
The valgrind output is caused by bad alignment/size calculation, but even with that fixed (see 74c2ec9) rustc is crashing with a SIGFPU. It appears to be caused by gcc doing incorrect codegen and overflowing the x87 stack, but I haven't been able to confirm that. |
Right, I was building 346da18. I've now built 74c2ec9 with GCC 5.5.0. It fails with
Is this what you are referring to? |
No... (notes to test cargo with new code) - rustc should compile, but is crashing with SIGFPE |
Ok, dd4e3c8 builds again. Thanks. |
Also fyi, dd4e3c8 does not currently finish on x86_64 (GCC 5.5) either. I'm getting a SIGABRT here:
|
Here's a fresh log when attempting to build for i686-linux, using mrustc at commit 474bec9 to bootstrap from 1.39 (GNU Guix with GCC 10.3.0).
|
Confirmed, part of it is basic issue with |
The above commits fixed the asm issues on my testing machine, and allows it to build a basic "hello, world" |
Hello! I tried to build with the latest commit on x86_64 to get started, and it failed like so while building cargo via minicargo:
Any ideas? If I can get passed this bump, I'll test with i686-linux! |
On current master, attempting to build for i686-linux fails early like:
|
@thepowersgang OK, x86_64 can now build cargo again, but on i686-linux it fails early still with:
thanks for the support! |
Cause: mrustc/src/trans/codegen_c.cpp Line 6175 in 832b512
It was assuming that usize is always 64-bit |
Nice! How did you find out about it? |
Reading the generated code, adding |
Eh, it got really far this time, before failing on this:
|
Aah, good old librustc chewing memory. Will need to look into a way of reducing memory usage while calling gcc. |
@thepowersgang Do you think there's a way the generated code could cause GCC to be less memory-hungry? Or perhaps getting |
I was thinking of doing a lot of memory cleanup before invoking |
Would it really help if we are bound by 32-bit addressing limit of 4 GiB? |
438707880 = 0x1A26_26A8 Seems like it's just out of RAM (not out of address space)? |
I'd rather think we're hitting a 32-bit limit because building fails on a machine with 32 GiB of RAM and 16 GiB of swap:
|
Ooh, and yeah - 2GB limit: 0x1A26_26A8 + 0x5AF_3000 > 0x8000_0000 |
Sharing the experiment of another fellow Guix user:
This suggests playing with GCC flags alone won't be enough to have it built on i686. |
Maybe some sort of splitting up of the source file would work - would be rather complex (and likely will cause longer compiles for non-32bit platforms). |
I somehow managed to compile it under 3GiB under x86_64 with a 5.19.12 kernel. I used the following commit:
I then created a limited memory cgroup with cgroup v2 and this script:
I then build like that:
It then fails with the following error:
In the same shell I then re-launch the build again:
And at the end it finishes. Now, cgroups v2 doesn't impose any hard limit on the memory usage, so we need to validate that it was under 3GiB and for that we need a recent kernel to get the memory.peak file in sysfs which records the peak memory used. I've written a naive script to check that:
And with the settings above at the end of the build we have:
So that means that somehow with cgroup and with restarting the build we can build it under 3GiB. I'm not sure why it works better with cgroups than without. On i686 without cgroup it just fails to build, but I should probably try again and restart the build again when it fails. The bonus here is that (given a recent kernel) we now have a way to track the maximum memory usage. If I give it 4GiB, it somehow goes over the 4GiB but again I need to try again to restart the build to understand if we can just workaround by assuming that the build will fail and restart it a given number of times until it works. edit1: fixed some (markdown?) formatting |
Opening this so we have a place to track remaining issues for x86 support.
Building 42bdc18 with GCC 5.5 fails as below:
The text was updated successfully, but these errors were encountered: