| Message ID | 558B280E-4993-4FC6-9A57-A12ECB4A9B10@comcast.net |
|---|---|
| State | New |
| Headers | show |
On Jul 22, 2014, at 12:14 PM, Mike Stump <mikestump@comcast.net> wrote: > On Jul 22, 2014, at 4:01 AM, Kyrill Tkachov <kyrylo.tkachov@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?
On Wed, Jul 30, 2014 at 10:35 PM, Mike Stump <mikestump@comcast.net> wrote: > On Jul 22, 2014, at 12:14 PM, Mike Stump <mikestump@comcast.net> wrote: >> On Jul 22, 2014, at 4:01 AM, Kyrill Tkachov <kyrylo.tkachov@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
On Jul 31, 2014, at 3:55 PM, Ramana Radhakrishnan <ramana.gcc@googlemail.com> wrote: > 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 test suite ? A link editor test suite to ensure you implemented complex things in the linker is a fine place for such a tescase. The gcc test suite isn’t a place for such a test case if you want to test other than it works ok when it fits and to have it marked as unsupported if it doesn’t. The gcc test suite generally speaking doesn’t have enough of a low level system view to manage the totality of the complexities. In reality, some folks have a meg of ram, and 64k of code and they want to run the test suite. There are test cases that won’t work, and it is rather impossible to split the hairs and say exactly when a test case will and won’t work. Let’s say your 1 byte inside the limits on ram for a test case T. Then, someone improved the compiler by adding an optimization that expands the code size by 4 bytes and makes it 30% faster. That goes in. We don’t want that test case to fail, just because it no longer fits. Wether is fits or not, is not something we get to know in the test suite; because we don’t get to know, we can’t pass or fail because of it. The best we can do is know when it passes and say PASS:, and notice when it doesn’t fit and say UNSUPPORTED:. > I may be missing something here but it does sound like we may want 2 > slightly different behaviours possible here. Nope. Consider: #define N 100*1024*1024 char a[N]; main() { } and 100 different systems that this test case will run this test one, some already invented and some yet to be invented. Let me focus on one of them. It is a demand paged virtual memory system. It has 32 megs of ram on the machine, let say, that is the only size the machine has ever had. Do we mark this as passing or failing? Hint I’ve engineered this so that you cannot win. The problem is, if you say fail, I say it is demand paged, and it works. If you say it works, I say it fails, because the demand paged memory system preallocated all the backing store from swap and there wasn’t enough swap space to support it. You can attempt to say, ah, but the test suite is turning complete and we can write some tcl code to check out much swap space there is and set it up correctly, then I retort that the environment impinges the data space on this machine, then you retort, but we can then check the environment, and then I retort, but another user on the machine can use swap, then you retort, but we can kill off all their processes, then I retort, no, we can’t, then you still wind up loosing. Now, maybe I’ve overlooked something trivial, maybe I don’t understand the entirety of the world your envisioning… If you want to describe it, feel free. In short, the gcc test suite is not the proper place to test veneers for ld. We can test some of that support, just there are limits to it.
diff --git a/gcc/testsuite/lib/gcc-defs.exp b/gcc/testsuite/lib/gcc-defs.exp index 69a5971..58c6a9f 100644 --- a/gcc/testsuite/lib/gcc-defs.exp +++ b/gcc/testsuite/lib/gcc-defs.exp @@ -154,7 +154,7 @@ proc ${tool}_exit { } { # proc ${tool}_check_unsupported_p { output } { - if [regexp "(^|\n)\[^\n\]*: region \[^\n\]* is full" $output] { + if [regexp "(^|\n)\[^\n\]*: region \[^\n\]* (is full|overflowed by )" $output] { return "memory full" } if { [istarget spu-*-*] && \ diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp index a758d47..bc6ba97 100644 --- a/gcc/testsuite/lib/gcc-dg.exp +++ b/gcc/testsuite/lib/gcc-dg.exp @@ -225,10 +225,11 @@ proc gcc-dg-prune { system text } { } } - # If we see "region xxx is full" then the testcase is too big for ram. - # This is tricky to deal with in a large testsuite like c-torture so - # deal with it here. Just mark the testcase as unsupported. - if [regexp "(^|\n)\[^\n\]*: region \[^\n\]* is full" $text] { + # If we see "region xxx is full" or "region xxx overflowed by " + # then the testcase is too big for ram. This is tricky to deal + # with in a large testsuite like c-torture so deal with it here. + # Just mark the testcase as unsupported. + if [regexp "(^|\n)\[^\n\]*: region \[^\n\]* (is full|overflowed by )" $text] { # The format here is important. See dg.exp. return "::unsupported::memory full" } diff --git a/gcc/testsuite/lib/objc.exp b/gcc/testsuite/lib/objc.exp index 5ecefa9..6a1c2e7 100644 --- a/gcc/testsuite/lib/objc.exp +++ b/gcc/testsuite/lib/objc.exp @@ -354,7 +354,7 @@ if { [info procs prune_warnings] == "" } then { # gld so we can tell what the error text will look like. proc ${tool}_check_unsupported_p { output } { - if [regexp "(^|\n)\[^\n\]*: region \[^\n\]* is full" $output] { + if [regexp "(^|\n)\[^\n\]*: region \[^\n\]* (is full|overflowed by )" $output] { return "memory full" } return ""