On Wed, Jul 30, 2014 at 10:35 PM, Mike Stump <mikest...@comcast.net> wrote: > On Jul 22, 2014, at 12:14 PM, Mike Stump <mikest...@comcast.net> wrote: >> On Jul 22, 2014, at 4:01 AM, Kyrill Tkachov <kyrylo.tkac...@arm.com> wrote: >>> These tests use very large arrays as part of their loop interchange testing >>> so they don't fit into the 1MiB binary size limit imposed by -mcmodel=tiny. >>> This causes errors at link-time. >> >>> Ok to commit? >> >> So the test suite should be used to figure this out as marking the >> individual test cases is a never ending and ever changing. I can a big test >> case on my system, and found: >> >> ld: address 0xc401ad0 of a.out section `.data' is not within region `SRAM' >> ld: a.out section `.ctors' will not fit in region `SRAM' >> ld: address 0xc401ad0 of a.out section `.data' is not within region `SRAM' >> ld: region `SRAM' overflowed by 155196160 bytes >> >> for large test cases. After looking at the current gld sources, it seems >> that they merely changed the spelling of the error message and we’ve not >> kept up. Please try the patch below and tell me if it works for you. If it >> doesn’t, what messages do you see and what tool are they from? Vendor, >> program and version would be nice to know. >> >> If it works, feel free to check it in. If you want to replicate the 4 lines >> and add a case for the vendor’s tool, that’d be a better way to handle it. >> The below should handle a variety of GNU ld situations (but not all of them). > > So, were you able to test the patch I sent?
So Kyrill's away and that's probably why he hasn't tested your patch yet. The particular errors are in the "tiny" memory model in AArch64 and the typical messages are about relocations truncated to fit. Now, in the tiny memory model on AArch64 it's valid to filter out the error messages that state that "relocation was truncated to fit" which is essentially that the program is too big. However if we have a situation where a port tries to ameliorate some of these errors with linker veneering and the compiler testsuite peels off such error messages and just marks them as UNSUPPORTED instead of getting a failure, is that the right behaviour in the testsuite ? I may be missing something here but it does sound like we may want 2 slightly different behaviours possible here. Ramana
