As discussed in an earlier thread, glibc makes certain assumptions about
the layout of the text, data, and bss segments of shared objects and
executables. One of those assumptions is that all segments of an
objects will be mapped consecutively.
The current elf64ppc.xB linker script unconditionally begins the BSS at
1.5T which virtually guarantees that something will be mapped between
the data segment and bss of the executable. This breaks the consecutive
mapping assumption and can cause application failures.
In many cases, the text, data, and bss can all fit below 4G. In this
case, BSS alignment can be reduced to 256M and executable segments can
be mapped much closer together. This patch contains a conditional ALIGN
statement so the case of a data segment extending beyond 4G can be
handled.
This patch resolves the dlopen problems we have been seeing lately with
some benchmark suites.
Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
diff -pur a/ldscripts/elf64ppc.xB b/ldscripts/elf64ppc.xB
--- a/ldscripts/elf64ppc.xB 2007-12-12 10:09:42.000000000 -0500
+++ b/ldscripts/elf64ppc.xB 2008-01-15 15:40:02.000000000 -0500
@@ -179,13 +179,14 @@ SECTIONS
. = ALIGN(64 / 8);
. = ALIGN(64 / 8);
. = DATA_SEGMENT_END (.);
- /* Hugepage area */
- /* Saving hugepages is more important than saving executable size, so
- * we don't attempt to maintain congruence here */
- . = ALIGN(0x18000000000); /* Move into next 1TB area, but use 1.5TB
- * instead of 1TB for compatibility with
- * old kernels that have a fixed hugepage
- * range */
+ /* Hugepage area:
+ * Saving hugepages is more important than saving executable size, so
+ * we don't attempt to maintain congruence here.
+ * In order to map hugepages into the address space, we must advance the
+ * location counter to a segment boundary. If the address is < 4G, the
+ * next segment will be on a 256M boundary. For higher areas, we have a
+ * 1TB granularity. */
+ . = (. < 0x100000000) ? ALIGN(0x10000000) : ALIGN(0x10000000000);
/* HACK: workaround fact that kernel may not cope with segments with zero
* filesize */
.hugetlb.data : { LONG(1) } :htlb
--
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libhugetlbfs-devel mailing list
Libhugetlbfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
