CREL relocations consume too much memory

[davidlattimore]

Chromium has switched to using CREL relocations by default when building if it thinks the linker is LLD. Wild supports CREL relocations, but apparently uses heaps more RAM when doing so.

I can sometimes link Chromium on my mini PC, which has 92GB of RAM. Apparently Wild hits peak RSS of 94GB, so I guess a little bit of swap space is being used. This is in contrast to linking Chromium without CREL relocations which hits peak RSS of less than 8GB.

You can switch whether Chromium is built with CREL relocations by editing build/config/compiler/BUILD.gn and commenting out the line that sets the flags -Wa,--crel,--allow-experimental-crel .

We currently copy all the CREL relocations for a section into a Vec so that we can access relocations by index. I'm not sure if a bidirectional CREL iterator is possible, but if it is, then we might not need the Vec. It'd probably also help if the CREL iterator was smaller. It's currently 80 bytes, so if we made lots of copies of different iterators, it might take up a bit of space. I'm not sure how practical it would be to reduce its size. I think the main spot where we would need lots of copied iterators is when storing the relocations for eh_frame for each section. Perhaps there's a different approach we could take there that might avoid the need for that, but I haven't thought too much about it yet.

[marxin]

Let me take a look at the issue - I think we can simplify the logic where we currently seek in the relocation stream (when finding a particular HI-LO part for the RISC-V target).