You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(11) |
2
(13) |
3
(7) |
|
4
(9) |
5
(23) |
6
(19) |
7
(18) |
8
(2) |
9
(7) |
10
(21) |
|
11
(13) |
12
|
13
(8) |
14
(17) |
15
(19) |
16
(25) |
17
(43) |
|
18
(22) |
19
(12) |
20
(19) |
21
(12) |
22
(9) |
23
(12) |
24
(5) |
|
25
(16) |
26
(25) |
27
(24) |
28
(19) |
29
(26) |
30
(25) |
31
(6) |
|
From: Jeremy F. <je...@go...> - 2004-07-26 21:55:45
|
On Mon, 2004-07-26 at 13:51 -0700, Bryan O'Sullivan wrote: > They do support 64-bit relocations; it's just not the default. The > issue is that all the system shobjs are compiled with the small code > model, so you can't mix and match code that has 32-bit relocations with > code that doesn't. I thought the tools only support small and medium, but not large? If we can stash all the Valgrind code below the main executable, small should be OK, right? Pointers are still 64-bit, so we can malloc stuff high? J |
|
From: Nicholas N. <nj...@ca...> - 2004-07-26 21:10:22
|
On Mon, 26 Jul 2004, Bryan O'Sullivan wrote: >>> - I changed kickstart_base to 0x70000000; having it at 0xb0000000 I get >>> lots of weird linker errors; it complains about truncations, I don't >>> understand. > > You're getting relocation errors because under the small x86_64 code > model, relocations are signed 32-bit quantities. Ah, that makes sense; that's why I couldn't go above 0x80000000. Is there any way around it? N |
|
From: Bryan O'S. <bo...@se...> - 2004-07-26 20:51:26
|
On Sun, 2004-07-25 at 19:51 -0700, Jeremy Fitzhardinge wrote: > On Sun, 2004-07-25 at 22:40 +0100, Nicholas Nethercote wrote: > > Now I'm fighting through the startup stuff. I'm proceeding until > > something breaks, then I try to fix it. Or ignore it, if it doesn't look > > too dangerous. Here's what I've done so far, perhaps people can assist... > > > > - I noticed that the s/start/_ume_entry in stage2.lds is unnecessary since > > the -Wl,-e,_ume_entry option is passed to stage2. No matter. > > > > - I changed kickstart_base to 0x70000000; having it at 0xb0000000 I get > > lots of weird linker errors; it complains about truncations, I don't > > understand. > > Are you generating a x86-32 or -64 executable? If the former, surely > you'd be using the same binutils as on a plain x86-32 machine? You're getting relocation errors because under the small x86_64 code model, relocations are signed 32-bit quantities. > Unfortunately the x86-64 tools don't support generating code with 64-bit > relocations, so all code must be below 4G (I think including .so's). They do support 64-bit relocations; it's just not the default. The issue is that all the system shobjs are compiled with the small code model, so you can't mix and match code that has 32-bit relocations with code that doesn't. <b |
|
From: Jeremy F. <je...@go...> - 2004-07-26 19:55:43
|
On Mon, 2004-07-26 at 16:54 +0100, Nicholas Nethercote wrote: > Jeremy, > > I think the as_pad() call in vg_main.c:layout_client_space() is redundant. > It pads the area VG_(client_base)..VG_(valgrind_base) (which is > 0..0xb0000000). > > But in stage1.c:hoops(), just before stage2 is launched, there is another > as_pad() which does the area 0..info.map_base (0..0xb1000000). > > So I think the second one is redundant, both with the current values of > the relevant variables, and any future ones (since VG_(client_base) will > always be >= 0, and VG_(valgrind_base) will always be < info.mapbase. > > The attached diff removes the redundant as_pad() in vg_main.c, which > allows layout_client_space() to merge with layout_remaining_space. It > works fine on my machine. Does it seem ok to you? I'll commit if so. That seems OK, but I think I put the second as_pad there deliberately, even though its redundant. Mainly, I think, to reduce the number of implicit dependencies between stage1 and stage2. The as_pad in stage1 is functionally there to make sure that stage2 loads in the right place; the one in stage2 is to make sure the tools load in the right place. Hm, it isn't a very strong reason for keeping it there. J |
|
From: Jeremy F. <je...@go...> - 2004-07-26 19:52:11
|
On Mon, 2004-07-26 at 16:55 +0100, Tom Hughes wrote: > Bug 86000 points out a race condition in our shmat() implementation. > > The problem is that if the user doesn't specify an address to map the > shared memory at then valgrind calls VG_(find_map_space) to find some > space and passes that address to the system call. > > It doesn't call VG_(map_segment) to reserve the space until after the > call returns however, and as shmat is part of the IPC system call that > is treated as blocking this means that the address space may get used > for something else before the system call is actually issued and the > system call will then fail. > > I've got a patch to call VG_(map_segment) before the system call is > made so that the space is reserved and won't be issued to anybody else > and that does seem to solve the problem. > > It introduces a new problem however in that if the system call fails > then POST(ipc) is never called and so the address space can't be released > and will effectively be leaked. > > Anybody got any good solutions? There's a few syscalls in which POST should be called on error exit (nanosleep, for example, needs to return the amount of unslept time on interrupt). I've been thinking that we should change may_block in sys_info into a bitfield, and encode a little more in there - like whether the syscall wants POST called on failure. (Another reason for this would be to allow conditional may_block-ness. Change PRE() to return a boolean, and add a flag into sys_info saying use the result of PRE rather than a fixed value for blockness. We could just change all the PREs to return the appropriate thing, or just use the existing value in the table.) J |
|
From: Jeremy F. <je...@go...> - 2004-07-26 19:49:34
|
On Mon, 2004-07-26 at 10:35 +0100, Nicholas Nethercote wrote: > On Sun, 25 Jul 2004, Jeremy Fitzhardinge wrote: > > > Are you generating a x86-32 or -64 executable? If the former, surely > > you'd be using the same binutils as on a plain x86-32 machine? > > x86-64. I'm aiming just at running 64-bit code first, then I'll worry > about 32-bit code. I'm not sure how much mixing of 32-bit and 64-bit code > is possible, that could become interesting. Well, I think there's definite benefits in running 32-bit code in 64-bit mode if available, because of all the extra address space and registers. > On x86-64, 64-bit executable get mapped to 0x400000 -- that's only 4MB > above zero. 32-bit executables get mapped to 0x8048000 as on x86 but > libraries get loaded very low, eg. 0x552000. So going below the > executable doesn't look feasible. I hadn't realized it was that low. But 4M is a lot of code - we can easily fit stage2, a tool and libc into 4M (especially if we change all the large static tables in core, memcheck and addrcheck to allocated memory). > > The VG_() stuff is somewhat redundant now, since nothing is "exported" > > in the same way. That is, we don't need to do name mangling to prevent > > namespace clashes with the client libraries. > > Why not? I like the VG_() anyway as it marks the exported functions > clearly. Well, with FV the client and Valgrind don't share a dynamic linker, so their symbols are in entirely different namespaces. The VG_() is from the LD_PRELOAD days to stop Valgrind's symbol names from overlapping with the clients. By "export", what do you mean? Exported to whom? Mostly they're internal; some are available for tool use, but there's no distinction made in the naming - it just depends on which header file they're declared in. J |
|
From: Jeremy F. <je...@go...> - 2004-07-26 17:09:08
|
On Mon, 2004-07-26 at 16:50 +0100, Tom Hughes wrote: > I'm not sure there's much we can do about this - arguably it's a > kernel bug anyway and the kernel should be allowing any thread in > the relevant process to make the call. Any ideas are gratefully > received however. Yup. I raised this on linux-kernel a while ago, and the consensus was that its a bug for the kernel to use the TID rather than the PID for these cases. J |
|
From: Nicholas N. <nj...@ca...> - 2004-07-26 16:21:42
|
CVS commit by nethercote:
Added some comments.
M +2 -0 ume.c 1.18
M +17 -10 ume.h 1.8
M +3 -2 vg_main.c 1.177 [POSSIBLY UNSAFE: printf]
--- valgrind/coregrind/ume.c #1.17:1.18
@@ -668,4 +668,6 @@ static int do_exec_inner(const char *exe
}
+// See ume.h for an indication of which entries of 'info' are inputs, which
+// are outputs, and which are both.
int do_exec(const char *exe, struct exeinfo *info)
{
--- valgrind/coregrind/ume.h #1.7:1.8
@@ -55,24 +55,30 @@ typedef ESZ(Addr) addr_t;
/*------------------------------------------------------------*/
+// Info needed to load and run a program. IN/INOUT/OUT refers to the
+// inputs/outputs of do_exec().
struct exeinfo
{
- addr_t map_base; // INPUT: if non-zero, base address of mappings
- char** argv; // INPUT: the original argv
+ addr_t map_base; // IN: if non-zero, base address of mappings
+ char** argv; // IN: the original argv
addr_t exe_base; // INOUT: lowest (allowed) address of exe
addr_t exe_end; // INOUT: highest (allowed) address
- addr_t phdr; // address phdr was mapped at
- int phnum; // number of phdrs
- addr_t interp_base; // where interpreter (ld.so) was mapped
- addr_t entry; // entrypoint in main executable
- addr_t init_eip; // initial eip
- addr_t brkbase; // base address of brk segment
+ addr_t phdr; // OUT: address phdr was mapped at
+ int phnum; // OUT: number of phdrs
+ addr_t interp_base; // OUT: where interpreter (ld.so) was mapped
+ addr_t entry; // OUT: entrypoint in main executable
+ addr_t init_eip; // OUT: initial eip
+ addr_t brkbase; // OUT: base address of brk segment
// These are the extra args added by #! scripts
- char* interp_name; // INPUT: the interpreter name
- char* interp_args; // INPUT: the args for the interpreter
+ char* interp_name; // OUT: the interpreter name
+ char* interp_args; // OUT: the args for the interpreter
};
+// Does everything short of actually running 'exe': finds the file,
+// checks execute permissions, sets up interpreter if program is a script,
+// reads headers, maps file into memory, and returns important info about
+// the program.
int do_exec(const char *exe, struct exeinfo *info);
@@ -85,4 +91,5 @@ void foreach_map(int (*fn)(void *start,
int maj, int min, int ino));
+// Padding functions used at startup to force things where we want them.
void as_pad(void *start, void *end);
void as_unpad(void *start, void *end);
--- valgrind/coregrind/vg_main.c #1.176:1.177
@@ -1453,4 +1452,5 @@ static void load_client(char* cl_argv[],
if (need_help) {
VG_(clexecfd) = -1;
+ // Set the minimal number of entries in 'info' to continue.
info->interp_name = NULL;
info->interp_args = NULL;
@@ -1460,5 +1460,6 @@ static void load_client(char* cl_argv[],
ret = do_exec(exec, info);
if (ret != 0) {
- fprintf(stderr, "valgrind: do_exec(%s) failed: %s\n", exec, strerror(ret));
+ fprintf(stderr, "valgrind: do_exec(%s) failed: %s\n",
+ exec, strerror(ret));
exit(127);
}
|
|
From: Tom H. <th...@cy...> - 2004-07-26 15:55:45
|
Bug 86000 points out a race condition in our shmat() implementation. The problem is that if the user doesn't specify an address to map the shared memory at then valgrind calls VG_(find_map_space) to find some space and passes that address to the system call. It doesn't call VG_(map_segment) to reserve the space until after the call returns however, and as shmat is part of the IPC system call that is treated as blocking this means that the address space may get used for something else before the system call is actually issued and the system call will then fail. I've got a patch to call VG_(map_segment) before the system call is made so that the space is reserved and won't be issued to anybody else and that does seem to solve the problem. It introduces a new problem however in that if the system call fails then POST(ipc) is never called and so the address space can't be released and will effectively be leaked. Anybody got any good solutions? Tom -- Tom Hughes (th...@cy...) Software Engineer, Cyberscience Corporation http://www.cyberscience.com/ |
|
From: Nicholas N. <nj...@ca...> - 2004-07-26 15:55:06
|
Jeremy, I think the as_pad() call in vg_main.c:layout_client_space() is redundant. It pads the area VG_(client_base)..VG_(valgrind_base) (which is 0..0xb0000000). But in stage1.c:hoops(), just before stage2 is launched, there is another as_pad() which does the area 0..info.map_base (0..0xb1000000). So I think the second one is redundant, both with the current values of the relevant variables, and any future ones (since VG_(client_base) will always be >= 0, and VG_(valgrind_base) will always be < info.mapbase. The attached diff removes the redundant as_pad() in vg_main.c, which allows layout_client_space() to merge with layout_remaining_space. It works fine on my machine. Does it seem ok to you? I'll commit if so. N |
|
From: Tom H. <th...@cy...> - 2004-07-26 15:50:58
|
We now have a couple of bugs (85373 and 85969) about system calls which no longer work in valgrind 2.1 due to the fact that blocking system calls are now run in a different thread. In each case the one of the system call arguments is a PID and the kernel is checking that if the caller is an unprivileged process then the PID passed must be the caller's PID. The is that the kernel only checks against the PID of the thread which called the system call rather than allowing any thread in that process to make the call. Hence if the system call is blocking and valgrind issues it in a different thread the call fails. I'm not sure there's much we can do about this - arguably it's a kernel bug anyway and the kernel should be allowing any thread in the relevant process to make the call. Any ideas are gratefully received however. Tom -- Tom Hughes (th...@cy...) Software Engineer, Cyberscience Corporation http://www.cyberscience.com/ |
|
From: Nicholas N. <nj...@ca...> - 2004-07-26 15:41:08
|
CVS commit by nethercote:
Rename 'argv0' and 'argv1' to the more meaningful 'interp_name' and
'interp_args'.
M +8 -8 ume.c 1.17 [POSSIBLY UNSAFE: printf]
M +2 -2 ume.h 1.7
M +13 -13 vg_main.c 1.176
--- valgrind/coregrind/ume.c #1.16:1.17
@@ -566,9 +566,9 @@ static int load_script(char *hdr, int le
}
- info->argv0 = strdup(interp);
- assert(NULL != info->argv0);
+ info->interp_name = strdup(interp);
+ assert(NULL != info->interp_name);
if (arg != NULL && *arg != '\0') {
- info->argv1 = strdup(arg);
- assert(NULL != info->argv1);
+ info->interp_args = strdup(arg);
+ assert(NULL != info->interp_args);
}
@@ -577,6 +577,6 @@ static int load_script(char *hdr, int le
if (0)
- printf("#! script: argv0=\"%s\" argv1=\"%s\"\n",
- info->argv0, info->argv1);
+ printf("#! script: interp_name=\"%s\" interp_args=\"%s\"\n",
+ info->interp_name, info->interp_args);
return do_exec_inner(interp, info);
@@ -670,6 +670,6 @@ static int do_exec_inner(const char *exe
int do_exec(const char *exe, struct exeinfo *info)
{
- info->argv0 = NULL;
- info->argv1 = NULL;
+ info->interp_name = NULL;
+ info->interp_args = NULL;
return do_exec_inner(exe, info);
--- valgrind/coregrind/ume.h #1.6:1.7
@@ -71,6 +71,6 @@ struct exeinfo
// These are the extra args added by #! scripts
- char* argv0; // INPUT: the interpreter name
- char* argv1; // INPUT: the args for the interpreter
+ char* interp_name; // INPUT: the interpreter name
+ char* interp_args; // INPUT: the args for the interpreter
};
--- valgrind/coregrind/vg_main.c #1.175:1.176
@@ -1014,11 +1014,11 @@ static Addr setup_client_stack(char **or
interpreter and its argument) */
argc = 0;
- if (info->argv0 != NULL) {
+ if (info->interp_name != NULL) {
argc++;
- stringsize += strlen(info->argv0) + 1;
+ stringsize += strlen(info->interp_name) + 1;
}
- if (info->argv1 != NULL) {
+ if (info->interp_args != NULL) {
argc++;
- stringsize += strlen(info->argv1) + 1;
+ stringsize += strlen(info->interp_args) + 1;
}
@@ -1092,11 +1092,11 @@ static Addr setup_client_stack(char **or
/* --- argv --- */
- if (info->argv0) {
- *ptr++ = (addr_t)copy_str(&strtab, info->argv0);
- free(info->argv0);
+ if (info->interp_name) {
+ *ptr++ = (addr_t)copy_str(&strtab, info->interp_name);
+ free(info->interp_name);
}
- if (info->argv1) {
- *ptr++ = (addr_t)copy_str(&strtab, info->argv1);
- free(info->argv1);
+ if (info->interp_args) {
+ *ptr++ = (addr_t)copy_str(&strtab, info->interp_args);
+ free(info->interp_args);
}
for (cpp = orig_argv; *cpp; ptr++, cpp++) {
@@ -1453,6 +1453,6 @@ static void load_client(char* cl_argv[],
if (need_help) {
VG_(clexecfd) = -1;
- info->argv0 = NULL;
- info->argv1 = NULL;
+ info->interp_name = NULL;
+ info->interp_args = NULL;
} else {
Int ret;
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-26 15:28:42
|
CVS commit by nethercote:
Neaten up ume.h: don't export readelf(), mapelf, and struct elfinfo; improve
formatting too.
M +7 -0 ume.c 1.16
M +39 -24 ume.h 1.6
--- valgrind/coregrind/ume.c #1.15:1.16
@@ -51,4 +51,11 @@
#include "vg_include.h"
+struct elfinfo
+{
+ ESZ(Ehdr) e;
+ ESZ(Phdr) *p;
+ int fd;
+};
+
static int padfile = -1;
static struct stat padstat;
--- valgrind/coregrind/ume.h #1.5:1.6
@@ -1,3 +1,8 @@
+/*--------------------------------------------------------------------*/
+/*--- A header file used by both stage1 and stage2. ---*/
+/*--- ume.h ---*/
+/*--------------------------------------------------------------------*/
+
/*
This file is part of Valgrind, an extensible x86 protected-mode
@@ -31,4 +36,8 @@
#include <sys/types.h>
+/*------------------------------------------------------------*/
+/*--- General stuff ---*/
+/*------------------------------------------------------------*/
+
#if ELFSZ == 64
#define ESZ(x) Elf64_##x
@@ -42,27 +51,34 @@
typedef ESZ(Addr) addr_t;
+/*------------------------------------------------------------*/
+/*--- Loading ELF files ---*/
+/*------------------------------------------------------------*/
+
struct exeinfo
{
- addr_t map_base; /* INPUT: if non-zero, base address of mappings */
-
- addr_t exe_base; /* INOUT: lowest (allowed) address of exe */
- addr_t exe_end; /* INOUT: highest (allowed) address */
+ addr_t map_base; // INPUT: if non-zero, base address of mappings
+ char** argv; // INPUT: the original argv
- addr_t phdr; /* address phdr was mapped at */
- int phnum; /* number of phdrs */
- addr_t interp_base; /* where interpreter (ld.so) was mapped */
- addr_t entry; /* entrypoint in main executable */
- addr_t init_eip; /* initial eip */
- addr_t brkbase; /* base address of brk segment */
+ addr_t exe_base; // INOUT: lowest (allowed) address of exe
+ addr_t exe_end; // INOUT: highest (allowed) address
- /* these are the extra args added by #! scripts */
- char *argv0; /* INPUT: the interpreter name */
- char *argv1; /* INPUT: the args for the interpreter */
+ addr_t phdr; // address phdr was mapped at
+ int phnum; // number of phdrs
+ addr_t interp_base; // where interpreter (ld.so) was mapped
+ addr_t entry; // entrypoint in main executable
+ addr_t init_eip; // initial eip
+ addr_t brkbase; // base address of brk segment
- char **argv; /* INPUT: the original argv */
+ // These are the extra args added by #! scripts
+ char* argv0; // INPUT: the interpreter name
+ char* argv1; // INPUT: the args for the interpreter
};
int do_exec(const char *exe, struct exeinfo *info);
+/*------------------------------------------------------------*/
+/*--- Address space padding ---*/
+/*------------------------------------------------------------*/
+
void foreach_map(int (*fn)(void *start, void *end,
const char *perm, off_t offset,
@@ -74,13 +91,7 @@ int as_getpadfd(void);
void as_setpadfd(int);
-struct elfinfo
-{
- ESZ(Ehdr) e;
- ESZ(Phdr) *p;
- int fd;
-};
-
-struct elfinfo *readelf(int fd, const char *filename);
-ESZ(Addr) mapelf(struct elfinfo *e, ESZ(Addr) base);
+/*------------------------------------------------------------*/
+/*--- Finding and dealing with auxv ---*/
+/*------------------------------------------------------------*/
struct ume_auxv
@@ -101,2 +112,6 @@ struct ume_auxv *find_auxv(int *orig_esp
#endif /* _COREGRIND_UME_H */
+
+/*--------------------------------------------------------------------*/
+/*--- end ume.h ---*/
+/*--------------------------------------------------------------------*/
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-26 12:44:50
|
CVS commit by nethercote:
Remove accidental double assignment. Also don't assume that VG_(client_base)
is zero.
M +2 -3 vg_main.c 1.175
--- valgrind/coregrind/vg_main.c #1.174:1.175
@@ -507,8 +507,7 @@ static void layout_remaining_space(float
VG_(client_end) = VG_(client_base) + client_size;
- VG_(client_mapbase) = PGROUNDDN((client_size/4)*3); /* where !FIXED mmap goes */
-
/* where !FIXED mmap goes */
- VG_(client_mapbase) = PGROUNDDN((addr_t)(client_size * CLIENT_HEAP_PROPORTION));
+ VG_(client_mapbase) = VG_(client_base) +
+ PGROUNDDN((addr_t)(client_size * CLIENT_HEAP_PROPORTION));
VG_(shadow_base) = VG_(client_end) + REDZONE_SIZE;
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-26 11:12:07
|
CVS commit by nethercote:
Er, actually make this test meaningful. It now aborts correctly if you try to
launch stage2 directly, rather than giving an obscure error about the tool
later on.
M +2 -2 vg_main.c 1.174 [POSSIBLY UNSAFE: printf]
--- valgrind/coregrind/vg_main.c #1.173:1.174
@@ -474,6 +474,6 @@ static void scan_auxv(void)
}
- if ( ! (1|2) ) {
- fprintf(stderr, "stage2 must be launched by stage1\n");
+ if ( found != (1|2) ) {
+ fprintf(stderr, "valgrind: stage2 must be launched by stage1\n");
exit(127);
}
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-26 10:22:40
|
CVS commit by nethercote:
Remove unused global variable.
M +0 -3 stage1.c 1.14
--- valgrind/coregrind/stage1.c #1.13:1.14
@@ -48,5 +48,4 @@
static int stack[SIGSTKSZ*4];
-static int our_argc;
/* Where we expect to find all our aux files (namely, stage2) */
@@ -218,6 +217,4 @@ int main(int argc, char **argv)
assert(ume_exec_esp != NULL);
- our_argc = argc;
-
/* Set the address space limit as high as it will go, since we make
a lot of very large mappings. */
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-26 10:06:12
|
CVS commit by nethercote:
make non-exported function static
M +1 -1 ume.c 1.15
--- valgrind/coregrind/ume.c #1.14:1.15
@@ -56,5 +56,5 @@ static struct stat padstat;
extern int kickstart_base; /* linker created */
-void check_mmap(void* res, void* base, int len)
+static void check_mmap(void* res, void* base, int len)
{
if ((void*)-1 == res) {
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-26 09:35:12
|
On Sun, 25 Jul 2004, Jeremy Fitzhardinge wrote: > Are you generating a x86-32 or -64 executable? If the former, surely > you'd be using the same binutils as on a plain x86-32 machine? x86-64. I'm aiming just at running 64-bit code first, then I'll worry about 32-bit code. I'm not sure how much mixing of 32-bit and 64-bit code is possible, that could become interesting. > For 64-bit processes, we're going to have some interesting issues here. > Ideally we should be able to run x86-32 programs under Valgrind with the > process in a 64-bit configuration, so that Valgrind can exist entirely > outside the 4G address space, leaving the whole thing for client use. > Unfortunately the x86-64 tools don't support generating code with 64-bit > relocations, so all code must be below 4G (I think including .so's). > But at least we can put all the heap/shadow/etc above 4G. > > But at the very least, since we have a full 4G address space to use, we > don't need to make any consideration for the kernel portion (ie, we can > put Valgrind up at e8000000 or something. > > I think ultimately, for a full 64-bit process version, we're going to > have to use another address space configuration. I'm thinking of > putting the code down very low (below the client executable, say from > 4M-16M), and sticking all the data up very high (~512Gbyte, or > something). That way the client gets a large address space in between > to play with. On x86-64, 64-bit executable get mapped to 0x400000 -- that's only 4MB above zero. 32-bit executables get mapped to 0x8048000 as on x86 but libraries get loaded very low, eg. 0x552000. So going below the executable doesn't look feasible. >> - fix_auxv() isn't working, because there are apparently only 2 auxv > > Strange. I suspect there's some dodgy code which assumes sizeof(int) == > sizeof(void *) in there. Yes, I changed that and it's working now. sizeof(argc) is actually 8-bytes; I'm seeing that in a few places, eg. syscalls, where things that are ints in C are actually 8-bytes... it's a bit confusing. > The VG_() stuff is somewhat redundant now, since nothing is "exported" > in the same way. That is, we don't need to do name mangling to prevent > namespace clashes with the client libraries. Why not? I like the VG_() anyway as it marks the exported functions clearly. N |
|
From: <js...@ac...> - 2004-07-26 03:01:16
|
Nightly build on nemesis ( SuSE 9.1 ) started at 2004-07-26 03:50:01 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 168 tests, 4 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Jeremy F. <je...@go...> - 2004-07-26 02:51:24
|
On Sun, 2004-07-25 at 22:40 +0100, Nicholas Nethercote wrote:
> Now I'm fighting through the startup stuff. I'm proceeding until
> something breaks, then I try to fix it. Or ignore it, if it doesn't look
> too dangerous. Here's what I've done so far, perhaps people can assist...
>
> - I noticed that the s/start/_ume_entry in stage2.lds is unnecessary since
> the -Wl,-e,_ume_entry option is passed to stage2. No matter.
>
> - I changed kickstart_base to 0x70000000; having it at 0xb0000000 I get
> lots of weird linker errors; it complains about truncations, I don't
> understand.
Are you generating a x86-32 or -64 executable? If the former, surely
you'd be using the same binutils as on a plain x86-32 machine?
For 64-bit processes, we're going to have some interesting issues here.
Ideally we should be able to run x86-32 programs under Valgrind with the
process in a 64-bit configuration, so that Valgrind can exist entirely
outside the 4G address space, leaving the whole thing for client use.
Unfortunately the x86-64 tools don't support generating code with 64-bit
relocations, so all code must be below 4G (I think including .so's).
But at least we can put all the heap/shadow/etc above 4G.
But at the very least, since we have a full 4G address space to use, we
don't need to make any consideration for the kernel portion (ie, we can
put Valgrind up at e8000000 or something.
I think ultimately, for a full 64-bit process version, we're going to
have to use another address space configuration. I'm thinking of
putting the code down very low (below the client executable, say from
4M-16M), and sticking all the data up very high (~512Gbyte, or
something). That way the client gets a large address space in between
to play with.
> - fix_auxv() isn't working, because there are apparently only 2 auxv
> entries, neither of which are the ones we want. On x86 there are usually
> 17 AFAICT. Any ideas? Does anyone know a program that reads auxv entries
> so I can check this is really happening? Currently, I'm just ignoring
> this matter and proceeding anyway.
Strange. I suspect there's some dodgy code which assumes sizeof(int) ==
sizeof(void *) in there.
> [Actually, the two entries are the added ones AT_UME_{PADFD,EXECFD}, which
> makes me think that the original auxv is getting clobbered somehow. I
> will investigate further.]
>
> - When ume_go() is called to call stage2's main(), I get a seg fault, I
> can't work out why. ume_go()'s x86 definition puzzles me:
>
> /*
> Jump to a particular EIP with a particular ESP. This is intended
> to simulate the initial CPU state when the kernel starts an program
> after exec; it therefore also clears all the other registers.
> */
> void ume_go(addr_t eip, addr_t esp)
> {
> asm volatile ("movl %1, %%esp;" /* set esp */
> "pushl %%eax;" /* push esp */
> "xorl %%eax,%%eax;" /* clear registers */
> "xorl %%ebx,%%ebx;"
> "xorl %%ecx,%%ecx;"
> "xorl %%edx,%%edx;"
> "xorl %%esi,%%esi;"
> "xorl %%edi,%%edi;"
> "xorl %%ebp,%%ebp;"
>
> "ret" /* return into entry */
> : : "a" (eip), "r" (esp));
> /* we should never get here */
> for(;;)
> asm volatile("ud2");
> }
>
> (I have of course changed this for x86-64.)
>
> I can't see how %eip is set by this -- I don't understand inline asm
> very well but there's no mention of %0, and what's the "pushl %eax" for?
> Is eip being passed in register %eax? Surely not without
> __attribute__((regparms(n)))?
Well, "a" (eip) sets %eax to equal eip. The push puts it on the stack,
and the ret jumps to *(esp) - ie, eip. The comment is wrong: it should
be
"pushl %%eax;" /* push eip */
> - I find the whole startup (up until stage2's main()) sequence very
> confusing. Several different files, several different headers, no use of
> the VG_() macro so it's hard to see what's exported and what's local, very
> few comments despite it doing some decidedly tricky stuff... hmm.
Sorry, my bad. The ume stuff is somewhat standalone, though there isn't
much point. Though ume is used in two distinct ways (to load stage2 and
to load the client).
The VG_() stuff is somewhat redundant now, since nothing is "exported"
in the same way. That is, we don't need to do name mangling to prevent
namespace clashes with the client libraries. There's a bit of a policy
decision to be made here - how much should Valgrind keep implementing
for itself, and how much should we use libc stuff. A lot of the VG_()
functions are simple duplicates of libc.
J
|
|
From: Tom H. <to...@co...> - 2004-07-26 02:25:13
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-07-26 03:20:01 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 173 tests, 7 stderr failures, 1 stdout failure ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-26 02:19:42
|
Nightly build on audi ( Red Hat 9 ) started at 2004-07-26 03:15:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 173 tests, 8 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) corecheck/tests/pth_cancel2 (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-26 02:13:24
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-07-26 03:10:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 173 tests, 4 stderr failures, 0 stdout failures ================= helgrind/tests/deadlock (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-26 02:08:16
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-07-26 03:05:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 173 tests, 6 stderr failures, 1 stdout failure ================= addrcheck/tests/toobig-allocs (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/new_nothrow (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-26 02:07:43
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-07-26 03:00:04 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow rcrl: valgrind ./rcrl readline1: valgrind ./readline1 resolv: valgrind ./resolv rlimit_nofile: valgrind ./rlimit_nofile seg_override: valgrind ./seg_override sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 173 tests, 0 stderr failures, 0 stdout failures ================= |