This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
>>>>> On 29 Apr 2002 14:35:29 -0700, Ulrich Drepper <drepper@redhat.com> said: Ulrich> Just for the records: testing the cvs trunk currently will Ulrich> not succeed on IA-64 (localedef aborts). The problem is in Ulrich> the kernel. ld.so is placed at a very unfortunate address Ulrich> which prevents larger allocation of memory. David will fix Ulrich> it. But we'll have to live with it for now. I should have cc'd libc-hacker. Sorry about that. --david -------------------------------------------------------------- From: David Mosberger <davidm@linux.hpl.hp.com> Sender: ia64_rd-admin@ldl.fc.hp.com To: linux-ia64@linuxia64.com Subject: [ia64 R&D] [patch] small but important change Date: Mon, 29 Apr 2002 14:40:32 -0700 Reply-To: davidm@hpl.hp.com X-URL: http://www.hpl.hp.com/personal/David_Mosberger/ Attached below is a one-liner that you may need to successfully build glibc. Without this change, you may see "make check" in the glibc build fail with "out of memory" error messages. The problem is due to the fact that ld.so, when invoked directly, had only 16MB of virtual memory available before bumping into the ld.so image. Eventually, this would cause brk() to fail. The fix below is to increase ELF_ET_DYN_BASE to give up to 32GB of virtual memory. Of course, you can still come up with test cases where there would be a conflict, but in practice, 32GB should carry us for a long time (and the fundamental problem is inherent in the UNIX process model). An alternative would be to place a directly-invoked loader in a different region, but I want to avoid that to minimize the number of user regions that the kernel requires for proper operation. Note that this issue comes up only when invoking relocatable ELF binaries (such as ld.so). With normal binaries, this issue won't occur because the break value ends up in region 3. NOTE TO DISTRIBUTORS: I'd like to encourage all distributions to include this change in the kernel used for the next distro release. It should be completely safe and avoids confusing errors during glibc builds (there may be other cases where this pops up, though I'm not aware of any). --david --- include/asm-ia64/elf.h~ Mon Apr 22 19:54:07 2002 +++ include/asm-ia64/elf.h Mon Apr 29 14:03:34 2002 @@ -39,7 +39,7 @@ * the way of the program that it will "exec", and that there is * sufficient room for the brk. */ -#define ELF_ET_DYN_BASE (TASK_UNMAPPED_BASE + 0x1000000) +#define ELF_ET_DYN_BASE (TASK_UNMAPPED_BASE + 0x800000000) /* _______________________________________________ ia64_rd mailing list ia64_rd@ldl.fc.hp.com http://ldl.fc.hp.com/cgi-bin/mailman/listinfo/ia64_rd
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |