On Aug 7, 2014, at 1:38 AM, Kyrill Tkachov <kyrylo.tkac...@arm.com> wrote: > > Thanks for the detailed explanation, the linker errors I was seeing were > about relocations being truncated.
Ah, those are bugs in your port! You should be able to generate large code and then relax it into short small code. Large code, by definition, will never run into relocs being truncated. :-) > I've extended your patch to catch those as well. With this the tests I was > seeing FAIL now are marked UNSUPPORTED. > How is this? No. :-( Those are traditionally bugs in gcc that users want gcc to fix. Paper overing those bugs is the wrong path forward. So, a couple of ideas come to mind. The best, add relation and generate large by default. Next solution, is to have a linker script that limits memory to the size that the large reloc supports. If it is 18 bits, then limit memory to 18 bits. Doesn’t impact normal users as they only have 18 bits or less on their system. Next up, add a -mcmodel=large and make it the default and have people that want small code use -mcmodel=small. Another solution is to add a non-default -mc-model=large, and generate large code with that option, and then fix the specific test cases in the gcc test suite that fail to use that option on your target. This is a small maintenance nightmare, but… So, which one do you like? The model option (I just got done doing one for mine). I was building gcc for my target, which only the simulator can run due to memory sizes and hit the relocs don’t fit. I fixed it by 2 lines of work, one in branch and one in call, that removed the displacement forms under large model. Generates gross code, but I only need it for testing. For production, we default to and use small. The reality is that while the other instruction might theoretically hit the reloc limits, in practice they don’t.
