Out of memory when rebuilding riscv-linux

[benjaminou4412]

So I've reached this point in the guide:

Enter to General Setup, mark "Initial RAM filesystem and RAM disk". Then go to the option "Initramfs source file" and press enter to change it to "rootfs.cpio". Then Exit all the way back and save to .config. Don't forget to rebuild riscv-linux and riscv-pk!

But when I run:

make -j4 ARCH=riscv CROSS_COMPILE=riscv64-unknown-linux-gnu- vmlinux

In the directory, after over an hour of building, it shows this error:

riscv64-unknown-linux-gnu/bin/as: out of memory allocating 7492466729 bytes after a total of 131072 bytes

free results:

total used free shared buff/cache available Mem: 3963856 1314632 1400908 58996 1248316 2281248 Swap: 4117500 268 4117232

Is there a way to fix this? Or does my system (a laptop running Ubuntu) just not have enough memory?

[jim-wilson]

Exactly which part of the build is failing? The assembler error isn't very informative and I'm a tools guy not a linux guy, so I'm not very familiar with linux builds. Presumably this caused a gcc command or makefile rule to fail, that would be a little more helpful.

You could try dropping the -j4, though if it really needs 7.5GB for one file you might be out of luck.

If you have plenty of free disk space, you could try adding more swap space, perhaps via a swapfile.

[jim-wilson]

You might try looking at sifive/freedom-u-sdk, which is much easier to build than riscv-tools. You can use "make qemu" to get linux+buildroot running on qemu. I don't know if this solves your problem with memory size though.

riscv-tools is primarily useful if you want to learn how to build a linux system from scratch. Otherwise, it is best to avoid it, as it is poorly maintained, and difficult to build.

[benjaminou4412]

Thanks for the help (this time and last time). I realize I'm going the most painful route trying to build the kernel from scratch, but I think I'm in the "unusual idea of fun" camp mentioned in the guide.

Making my system's swapfile huge seems to have solved the memory problem, but a new error has popped up which I can't parse at all:

make ARCH=riscv CROSS_COMPILE=riscv64-unknown-linux-gnu- vmlinux

CALL scripts/checksyscalls.sh

:1335:2: warning: #warning syscall rseq not implemented [-Wcpp] CHK include/generated/compile.h AS usr/initramfs_data.o AR usr/built-in.a GZIP kernel/config_data.gz GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o AR init/built-in.a AR built-in.a LD vmlinux.o MODPOST vmlinux.o arch/riscv/kernel/head.o: In function `_start': (.init.text+0x4): relocation truncated to fit: R_RISCV_PCREL_HI20 against symbol `__global_pointer$' defined in .sdata section in .tmp_vmlinux1 riscv64-unknown-linux-gnu-ld: final link failed: Invalid operation Makefile:1015: recipe for target 'vmlinux' failed make: *** [vmlinux] Error 1 A little digging shows that other people have run into similar-looking errors, but it seems like it's hard to diagnose. Any ideas?

[jim-wilson]

The relocation truncated error is a generic linker error. There are many different ways to hit this error. Other similar bug reports may not have any relationship to your problem.

I would try adding --noinhibit-exec to the link line, -Wl,--noinhibit-exec if using gcc to link. This will allow the output file to be created even though there is an error. You can then examine the output file with objdump to see what the addresses of __global_pointer$ and .init.text are, and try to figure out why you got the relocation truncated error.

If you aren't familiar with relocs, Palmer Dabbelt has a blog series that talks about relocs and other toolchain issues. https://www.sifive.com/blog/2017/08/21/all-aboard-part-2-relocations/

These riscv-tools instructions are old. It is possible that they don't work anymore. You could try comparing against a known working tree, such as the sifive/freedom-u-sdk tree.

[palmer-dabbelt]

My laptop has 8GiB of RAM and it can build RISC-V defconfigs fine, and there isn't enough information in here to actually debug the issue. I have a feeling you're trying to build a really big kernel, do you maybe have a giant initramfs?

Feel free to re-open it with a full sequence, but I'm going to close this unless there's a way to reproduce it.