To get 32-bit programs working on Opteron, VG_(valgrind_end) was recently
changed to name the last byte in Valgrind's section, rather than one past the
last byte. This was because the last byte is 0xffffffff, and so one past gave
0x0, which screwed things up.
However, when this change was made, all the places where VG_(valgrind_end) is
used weren't adjusted appropriately. So this commit makes those adjustments.
It also renames the variable as VG_(valgrind_last), which makes the difference
between it and the other VG_(*_end) variables much clearer.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2672 a5019735-40e9-0310-863c-91ae7b9d1cf9
diff --git a/coregrind/vg_main.c b/coregrind/vg_main.c
index b80e286..8ef52cc 100644
--- a/coregrind/vg_main.c
+++ b/coregrind/vg_main.c
@@ -108,11 +108,9 @@
Addr VG_(valgrind_base); /* valgrind's address range */
-// VG_(valgrind_end) has a slightly different meaning to all the other
-// VG_(*_end) vars -- ie. it names the last byte, whereas the others
-// go one byte past the end.
-
-Addr VG_(valgrind_end);
+// Note that VG_(valgrind_last) names the last byte of the section, whereas
+// the VG_(*_end) vars name the byte one past the end of the section.
+Addr VG_(valgrind_last);
vki_rlimit VG_(client_rlimit_data);
@@ -403,12 +401,7 @@
addr_t client_size, shadow_size;
VG_(valgrind_base) = (addr_t)&kickstart_base;
-
- // VG_(valgrind_end) has a slightly different meaning to all the other
- // VG_(*_end) vars -- ie. it names the last byte, whereas the others
- // go one byte past the end.
-
- VG_(valgrind_end) = ROUNDUP(argc_addr, 0x10000) - 1; // stack
+ VG_(valgrind_last) = ROUNDUP(argc_addr, 0x10000) - 1; // stack
// This gives the client the largest possible address space while
// taking into account the tool's shadow needs.
@@ -434,14 +427,14 @@
"shadow_base %8x (%dMB)\n"
"shadow_end %8x\n"
"valgrind_base %8x (%dMB)\n"
- "valgrind_end %8x\n",
+ "valgrind_last %8x\n",
VG_(client_base), SEGSIZE(client_base, client_mapbase),
VG_(client_mapbase), SEGSIZE(client_mapbase, client_end),
VG_(client_end), SEGSIZE(client_end, shadow_base),
VG_(shadow_base), SEGSIZE(shadow_base, shadow_end),
VG_(shadow_end),
- VG_(valgrind_base), SEGSIZE(valgrind_base, valgrind_end),
- VG_(valgrind_end)
+ VG_(valgrind_base), SEGSIZE(valgrind_base, valgrind_last),
+ VG_(valgrind_last)
);
#undef SEGSIZE
@@ -2277,7 +2270,7 @@
symbols. This is so we know where the free space is before we
start allocating more memory (note: heap is OK, it's just mmap
which is the problem here). */
- if (start >= VG_(valgrind_base) && (start+size) <= VG_(valgrind_end)) {
+ if (start >= VG_(valgrind_base) && (start+size-1) <= VG_(valgrind_last)) {
flags |= SF_VALGRIND;
VG_(map_file_segment)(start, size, prot, flags, dev, ino, foffset, filename);
}
@@ -2310,7 +2303,7 @@
if (filename != NULL)
flags |= SF_FILE;
- if (start >= VG_(valgrind_base) && (start+size) <= VG_(valgrind_end))
+ if (start >= VG_(valgrind_base) && (start+size-1) <= VG_(valgrind_last))
flags |= SF_VALGRIND;
VG_(map_file_segment)(start, size, prot, flags, dev, ino, foffset, filename);
@@ -2438,7 +2431,7 @@
| and mappings |
- -
| valgrind stack ^^^^^^^^^|
- valgrind_end +-------------------------+
+ valgrind_last +-------------------------+
: kernel :
Nb: Before we can do general allocations with VG_(arena_malloc)() and