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]

Re: ia-64 test problem


>>>>> 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]