Getting assert error due to 32/64-bit issues, but on a 64-bit OS in RuntimeDyldELF::resolveX86_64Relocation

Hello! I need some advice about an assert we’re getting. We’re using LLVM13 (which we compile ourselves), but this particular code hasn’t changed since then; it’s this line:

As far as I can tell, the problem is that the memory offset is larger than a 32-bit integer, so won’t work on the “ELF::R_X86_64_PC32” ‘type’. If the type had instead been ‘ELF::R_X86_64_PC64’, that assert would not have been needed (see the code immediately following).

However, this is running on 64-bit architecture, so I shouldn’t have this problem (I would have thought). So my question is: why is LLVM setting the ‘type’ here to ‘ELF::R_X86_64_PC32’? Is something going wrong in the compilation of LLVM itself? Is it something we can change manually? Was anything fixed with regard to setting this in the versions since LLVM13?

The problem ultimately stems from Support LLVM large code model · Issue #1091 · sys-bio/roadrunner · GitHub if that helps give more context. Thank you!

What’s the question? If you don’t ask for a large code model, you don’t get it, because it’s far more efficient to use a smaller one (and can come with position independence issues, too, for some architectures and ABIs). Reading your link it sounds like this was a case of “default code model doesn’t work but large does”, as expected?

If you are already using large code model, then somewhere there’s a 32-bit variable/field that needs to be 64-bit, but whose size isn’t affected by picking the large model. That might be in your code that’s being compiled. The information so far isn’t enough to tell where the problem is.

Just verifying that R_X86_64_PC32 is related to the small/large code model change is good, but yes, as surmised, recompiling with the ‘large’ model by default didn’t help, and we got the same assert.

I’m happy to provide more information, but am unsure where to start. What do you need to know?

You’d need to provide a reduced test case demonstrating the problem. I strongly suspect the code in question was not in fact compiled with a large code model. Compiler Explorer demonstrates the difference between the two.