valgrind/valgrind-3.6.0-pie.patch
Jakub Jelinek 4b7bdeb491 3.6.0-2
2011-01-28 13:42:00 +01:00

41 lines
1.9 KiB
Diff

From eb8d355b64e72bfdf1c8dd2534b1625d5d0118e0 Mon Sep 17 00:00:00 2001
From: Dodji Seketeli <dodji@seketeli.org>
Date: Thu, 13 Jan 2011 16:04:39 +0100
Subject: [PATCH] Fix crash loading certain binaries on ppc64
Increase the space left for VDSO on ppc64 compiled with 64KB page
size. the size of VDSO is at least 2 pages: one for the code and one
for the data. We ought to leave more than two page space then. The
patch leaves 8 pages space to comply with what is done already for 4KB
page sizes.
---
coregrind/m_ume/elf.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
--- valgrind/coregrind/m_ume/elf.c
+++ valgrind/coregrind/m_ume/elf.c
@@ -327,6 +327,7 @@ Int VG_(load_ELF)(Int fd, const HChar* name, /*MOD*/ExeInfo* info)
/* The kernel maps position-independent executables at TASK_SIZE*2/3;
duplicate this behavior as close as we can. */
if (e->e.e_type == ET_DYN && ebase == 0) {
+ ESZ(Addr) hacky_load_address;
ebase = VG_PGROUNDDN(info->exe_base
+ (info->exe_end - info->exe_base) * 2 / 3);
/* We really don't want to load PIEs at zero or too close. It
@@ -336,10 +337,11 @@ Int VG_(load_ELF)(Int fd, const HChar* name, /*MOD*/ExeInfo* info)
nonpointers. So, hackily, move it above 1MB. */
/* Later .. is appears ppc32-linux tries to put [vdso] at 1MB,
which totally screws things up, because nothing else can go
- there. So bump the hacky load addess along by 0x8000, to
- 0x108000. */
- if (ebase < 0x108000)
- ebase = 0x108000;
+ there. The size of [vdso] is around 2 or 3 pages, so bump
+ the hacky load addess along by 8 * VKI_PAGE_SIZE to be safe. */
+ hacky_load_address = 0x100000 + 8 * VKI_PAGE_SIZE;
+ if (ebase < hacky_load_address)
+ ebase = hacky_load_address;
}
info->phnum = e->e.e_phnum;