Re: other/9081: gcc doesn't diagnose, that the compiler exceeds a compiler limit

[Peter Bergner <bergner@vnet.ibm.com>]

The following reply was made to PR other/9081; it has been noted by GNATS.

From: Peter Bergner <bergner@vnet.ibm.com>
To: 133574@bugs.debian.org, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
   nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, pavel@atrey.karlin.mff.cuni.cz
Cc:  
Subject: Re: other/9081: gcc doesn't diagnose, that the compiler exceeds a
 compiler limit
Date: Mon, 27 Jan 2003 20:39:29 -0600

 We hit this same bug on ppc64 running 32-bit apps with the following
 testcase (32-bit apps get a full 4G of addr space to live in on ppc64):
 
      char x[2000000000];
 
      int
      main(void)
      {
          return 10;
      }
 
 Pavel is correct that all the calls to do_brk fail to test
 the return status of do_brk.  This is only part of the problem.
 The other major problem is that we don't call set_brk to reserve
 the bss region for the application until after we've already loaded
 the loader via the load_elf_interp() call.
 
 I have a patch that fixes both of those problems, but got delayed
 in posting since I was also trying to clean up what looks to be
 memory leaks in the error paths of load_elf_binary() before getting
 pulled away on another problem.  For example, it would seem the
 following code should be freeing some of the storage it allocaed
 before returning.  I'll try and clean up my patch and submit it.
 
          /* Do this so that we can load the interpreter, if need be.  We will
             change some of these later */
          current->mm->rss = 0;
          retval = setup_arg_pages(bprm);
          if (retval < 0) {
                  send_sig(SIGKILL, current, 0);
                  return retval;
          }
 
 Peter