On 08/08/14 18:53, Mike Stump wrote: > 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. >
Not quite, read the subject line again. This particular case the user (test) has asserted that the image will fit in a certain amount of memory; but in fact that turns out to be false. This can only be detected at link time when the relocations overflow - it's by definition impossible to detect during the compilation phase. I'm not sure what the correct change to the testsuite is here. Any test failures like this are likely to be somewhat target specific. In the worst case the optimization level may affect what can be made to fit. Perhaps the best solution would be something like marking the test as "large" in some way and for "large" tests the linker would handle "relocation truncated to fit" errors from the linker through some target hook that had a better understanding of whether size related options were being used and could decide between error and unsupported. R. > 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. >
