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
(8) |
2
(11) |
3
(21) |
4
(15) |
5
(10) |
|
6
(7) |
7
(7) |
8
(5) |
9
(7) |
10
(5) |
11
(1) |
12
(21) |
|
13
(8) |
14
(17) |
15
(6) |
16
(10) |
17
(7) |
18
(6) |
19
(15) |
|
20
(12) |
21
(16) |
22
(25) |
23
(14) |
24
(10) |
25
(7) |
26
(6) |
|
27
(34) |
28
(13) |
29
(10) |
30
(8) |
|
|
|
|
From: Mike H. <mik...@gm...> - 2004-06-21 21:17:42
|
Hi, In order to debug the wineserver (which is a regular Linux app), valgrind needs to support tkill. I am therefore following the advice in the README and asking here to see if anybody can give me some tips on how to do it, or if anybody is working on it yet. I see a VG_(ktkill) implementation but this doesn't seem to be what I'm looking for, it's not the emulated version. thanks -mike |
|
From: Nicholas N. <nj...@ca...> - 2004-06-21 17:48:07
|
On Mon, 21 Jun 2004, Julian Seward wrote: > Really it sounds like what's needed is a new version of GET and > PUT, which instead of taking a JIT-time-known arch register, > take an arch register number which is computed at runtime. Or a new instruction like LEA1 and LEA2 -- basically, it's just a new addressing mode. One that (unfortunately) would be used extremely rarely. N |
|
From: Julian S. <js...@ac...> - 2004-06-21 17:23:46
|
Really it sounds like what's needed is a new version of GET and PUT, which instead of taking a JIT-time-known arch register, take an arch register number which is computed at runtime. Then the running code can compute which arch register it wants to read and write. I guess it would also mean some care would have to be taken in the UCode optimisation phases, since any such "indirect" PUT/GET would mean all prior PUTs would have to be committed. But it's certainly doable. J On Monday 21 June 2004 14:15, Nicholas Nethercote wrote: > On Mon, 21 Jun 2004, Paul Mackerras wrote: > > > Sounds similar to the REP prefixed x86 instructions, which are done > > > with a JIFZ loop. > > > > It's not currently obvious to me how I get it to use a different > > register each time around the loop... > > Hmm, I see. What a sucky pair of instructions. > > You could do an awful hack of writing all registers to somewhere in memory > and then looping through them that way. (Hoping the instructions aren't > used very much, because it'll give awful performance.) Something similar > is currently done for the even-more-sucky x86 bt[src] instructions. > > N |
|
From: Darius I. <da...@ge...> - 2004-06-21 15:46:32
|
Hi all, I just wonder why in the coregrind/vg_libpthread.c and coregrind/arch/x86-linux/vg_libpthread.c, in the function pthread_rwlock_unlock(...) there are dublicated line: rwl = rw_remap ( orig ); rwl = rw_remap ( orig ); And another question: I looked at the vg_libpthread.c implementation for semaphores - they have se_unmap(...) function for clear out place in the se_remap_* array. I dont know if i'm right but it seems that it should work only for the last (se_remap_used) member released. Otherwise you are getting hole in the array - and the last member which is now in the position [se_remap_used+1] gets inaccessible. It is nevermind if im right or wrong, i just want to ask are you going to implement similar mechanism of reusing rw_remap_* entries because when test program allocates rw_locks dynamically i'm getting "VG_N_RWLOCKS is too low." very soon :( Best regards, -- Darius Ivanauskas P.S. You are developing WONDERFUL tool!!! |
|
From: Nicholas N. <nj...@ca...> - 2004-06-21 13:27:21
|
CVS commit by nethercote:
Streamlined --help message a bit.
M +7 -12 coregrind/vg_main.c 1.157
M +7 -12 none/tests/cmdline1.stdout.exp 1.5
M +7 -12 none/tests/cmdline2.stdout.exp 1.5
--- valgrind/coregrind/vg_main.c #1.156:1.157
@@ -1509,5 +1509,5 @@ void usage ( Bool debug_help )
"\n"
" common user options for all Valgrind tools, with defaults in [ ]:\n"
-" --tool=<name> Use the Valgrind tool named <name>\n"
+" --tool=<name> use the Valgrind tool named <name>\n"
" -h --help show this message\n"
" --help-debug show this message, plus debugging options\n"
@@ -1516,17 +1516,12 @@ void usage ( Bool debug_help )
" -v --verbose be more verbose, incl counts of errors\n"
" --trace-children=no|yes Valgrind-ise child processes? [no]\n"
-" --track-fds=no|yes Track open file descriptors? [no]\n"
+" --track-fds=no|yes track open file descriptors? [no]\n"
"\n"
" uncommon user options for all Valgrind tools:\n"
-" --run-libc-freeres=no|yes Free up glibc memory at exit? [yes]\n"
-" --weird-hacks=hack1,hack2,... [none]\n"
-" recognised hacks are: lax-ioctls\n"
-" --signal-polltime=<time> time, in mS, we should poll for signals.\n"
-" Only applies for older kernels which need\n"
-" signal routing [50]\n"
-" --lowlat-signals=no|yes improve wake-up latency when a thread receives\n"
-" a signal [no]\n"
-" --lowlat-syscalls=no|yes improve wake-up latency when a thread's\n"
-" syscall completes [no]\n"
+" --run-libc-freeres=no|yes free up glibc memory at exit? [yes]\n"
+" --weird-hacks=hack1,hack2,... recognised hacks: lax-ioctls [none]\n"
+" --signal-polltime=<time> signal poll period (mS) for older kernels [50]\n"
+" --lowlat-signals=no|yes improve thread signal wake-up latency [no]\n"
+" --lowlat-syscalls=no|yes improve thread syscall wake-up latency [no]\n"
" --pointercheck=no|yes enforce client address space limits [yes]\n"
"\n"
--- valgrind/none/tests/cmdline1.stdout.exp #1.4:1.5
@@ -2,5 +2,5 @@
common user options for all Valgrind tools, with defaults in [ ]:
- --tool=<name> Use the Valgrind tool named <name>
+ --tool=<name> use the Valgrind tool named <name>
-h --help show this message
--help-debug show this message, plus debugging options
@@ -9,17 +9,12 @@
-v --verbose be more verbose, incl counts of errors
--trace-children=no|yes Valgrind-ise child processes? [no]
- --track-fds=no|yes Track open file descriptors? [no]
+ --track-fds=no|yes track open file descriptors? [no]
uncommon user options for all Valgrind tools:
- --run-libc-freeres=no|yes Free up glibc memory at exit? [yes]
- --weird-hacks=hack1,hack2,... [none]
- recognised hacks are: lax-ioctls
- --signal-polltime=<time> time, in mS, we should poll for signals.
- Only applies for older kernels which need
- signal routing [50]
- --lowlat-signals=no|yes improve wake-up latency when a thread receives
- a signal [no]
- --lowlat-syscalls=no|yes improve wake-up latency when a thread's
- syscall completes [no]
+ --run-libc-freeres=no|yes free up glibc memory at exit? [yes]
+ --weird-hacks=hack1,hack2,... recognised hacks: lax-ioctls [none]
+ --signal-polltime=<time> signal poll period (mS) for older kernels [50]
+ --lowlat-signals=no|yes improve thread signal wake-up latency [no]
+ --lowlat-syscalls=no|yes improve thread syscall wake-up latency [no]
--pointercheck=no|yes enforce client address space limits [yes]
--- valgrind/none/tests/cmdline2.stdout.exp #1.4:1.5
@@ -2,5 +2,5 @@
common user options for all Valgrind tools, with defaults in [ ]:
- --tool=<name> Use the Valgrind tool named <name>
+ --tool=<name> use the Valgrind tool named <name>
-h --help show this message
--help-debug show this message, plus debugging options
@@ -9,17 +9,12 @@
-v --verbose be more verbose, incl counts of errors
--trace-children=no|yes Valgrind-ise child processes? [no]
- --track-fds=no|yes Track open file descriptors? [no]
+ --track-fds=no|yes track open file descriptors? [no]
uncommon user options for all Valgrind tools:
- --run-libc-freeres=no|yes Free up glibc memory at exit? [yes]
- --weird-hacks=hack1,hack2,... [none]
- recognised hacks are: lax-ioctls
- --signal-polltime=<time> time, in mS, we should poll for signals.
- Only applies for older kernels which need
- signal routing [50]
- --lowlat-signals=no|yes improve wake-up latency when a thread receives
- a signal [no]
- --lowlat-syscalls=no|yes improve wake-up latency when a thread's
- syscall completes [no]
+ --run-libc-freeres=no|yes free up glibc memory at exit? [yes]
+ --weird-hacks=hack1,hack2,... recognised hacks: lax-ioctls [none]
+ --signal-polltime=<time> signal poll period (mS) for older kernels [50]
+ --lowlat-signals=no|yes improve thread signal wake-up latency [no]
+ --lowlat-syscalls=no|yes improve thread syscall wake-up latency [no]
--pointercheck=no|yes enforce client address space limits [yes]
|
|
From: Nicholas N. <nj...@ca...> - 2004-06-21 13:15:31
|
On Mon, 21 Jun 2004, Paul Mackerras wrote: > > Sounds similar to the REP prefixed x86 instructions, which are done with a > > JIFZ loop. > > It's not currently obvious to me how I get it to use a different > register each time around the loop... Hmm, I see. What a sucky pair of instructions. You could do an awful hack of writing all registers to somewhere in memory and then looping through them that way. (Hoping the instructions aren't used very much, because it'll give awful performance.) Something similar is currently done for the even-more-sucky x86 bt[src] instructions. N |
|
From: Paul M. <pa...@sa...> - 2004-06-21 12:50:08
|
Nicholas Nethercote writes: > On Wed, 9 Jun 2004, Paul Mackerras wrote: > > > I do need to get in and implement the string load/store instructions. > > I have avoided them so far because I haven't hit the problem myself, and > > because doing lswx/stswx is going to be a bit interesting - uCode > > doesn't have a way to express loading a variable number of registers > > based on the contents of another register (XER). > > Sounds similar to the REP prefixed x86 instructions, which are done with a > JIFZ loop. It's not currently obvious to me how I get it to use a different register each time around the loop... I guess I could write a helper in C, but then it would presumably need to know about the instrumentation, or the instrumentation would need to know about it. Paul. |
|
From: Nicholas N. <nj...@ca...> - 2004-06-21 12:42:46
|
CVS commit by nethercote:
Renamed the following options:
--logfile-fd --> --log-fd
--logfile --> --log-file
--logsocket --> --log-socket
to be consistent with each other and other options (esp. --input-fd). Also
renamed some related variables. The old names still work, for backwards
compatibility, but they're not documented.
M +1 -1 FAQ.txt 1.22
M +11 -11 coregrind/vg_include.h 1.195
M +62 -48 coregrind/vg_main.c 1.156
M +5 -5 coregrind/vg_messages.c 1.10
M +2 -2 coregrind/vg_mylibc.c 1.73
M +2 -2 coregrind/vg_signals.c 1.70
M +4 -6 coregrind/vg_syscalls.c 1.102
M +11 -11 coregrind/docs/coregrind_core.html 1.30
M +2 -2 include/vg_skin.h.base 1.21
M +1 -1 memcheck/tests/error_counts.vgtest 1.2
M +3 -3 none/tests/cmdline1.stdout.exp 1.4
M +3 -3 none/tests/cmdline2.stdout.exp 1.4
--- valgrind/FAQ.txt #1.21:1.22
@@ -344,5 +344,5 @@
If you are tracing large trees of processes, it can be less disruptive
to have the output sent over the network. Give Valgrind the flag
---logsocket=127.0.0.1:12345 (if you want logging output sent to port
+--log-socket=127.0.0.1:12345 (if you want logging output sent to port
12345 on localhost). You can use the valgrind-listener program to
listen on that port:
--- valgrind/coregrind/vg_include.h #1.194:1.195
@@ -198,22 +198,22 @@ extern Bool VG_(clo_trace_children);
/* Where logging output is to be sent to.
- When log_to == VgLogTo_Fd, clo_logfile_fd holds the file id, and is
- taken from the command line. clo_logfile_name is irrelevant.
+ When log_to == VgLogTo_Fd, clo_log_fd holds the file id, and is
+ taken from the command line. clo_log_name is irrelevant.
- When log_to == VgLogTo_File, clo_logfile_name holds the logfile
- name, and is taken from the command line. clo_logfile_fd is then
- made to hold the relevant file id, by opening clo_logfile_name
+ When log_to == VgLogTo_File, clo_log_name holds the log-file
+ name, and is taken from the command line. clo_log_fd is then
+ made to hold the relevant file id, by opening clo_log_name
(concatenated with the process ID) for writing.
- When log_to == VgLogTo_Socket, clo_logfile_name holds the
+ When log_to == VgLogTo_Socket, clo_log_name holds the
hostname:portnumber pair, and is taken from the command line.
- clo_logfile_fd is then made to hold the relevant file handle, by
+ clo_log_fd is then made to hold the relevant file handle, by
opening a connection to said hostname:portnumber pair.
- Global default is to set log_to == VgLogTo_Fd and logfile_fd == 2
+ Global default is to set log_to == VgLogTo_Fd and log_fd == 2
(stderr). */
extern VgLogTo VG_(clo_log_to);
-extern Int VG_(clo_logfile_fd);
-extern Char* VG_(clo_logfile_name);
+extern Int VG_(clo_log_fd);
+extern Char* VG_(clo_log_name);
/* The file descriptor to read for input. default: 0 == stdin */
@@ -282,5 +282,5 @@ extern void VG_(intercept_libc_freeres_w
------------------------------------------------------------------ */
-/* Create a logfile into which messages can be dumped. */
+/* Create a log file into which messages can be dumped. */
extern void VG_(startup_logging) ( void );
extern void VG_(shutdown_logging)( void );
--- valgrind/coregrind/vg_main.c #1.155:1.156
@@ -1368,5 +1368,5 @@ static void abort_msg ( void )
{
VG_(clo_log_to) = VgLogTo_Fd;
- VG_(clo_logfile_fd) = 2; /* stderr */
+ VG_(clo_log_fd) = 2; /* stderr */
}
@@ -1466,6 +1466,6 @@ Bool VG_(clo_trace_children) = False;
immediately afterwards. */
VgLogTo VG_(clo_log_to) = VgLogTo_Fd;
-Int VG_(clo_logfile_fd) = 1;
-Char* VG_(clo_logfile_name) = NULL;
+Int VG_(clo_log_fd) = 1;
+Char* VG_(clo_log_name) = NULL;
Int VG_(clo_input_fd) = 0; /* stdin */
@@ -1532,7 +1532,7 @@ void usage ( Bool debug_help )
"\n"
" user options for Valgrind tools that report errors:\n"
-" --logfile-fd=<number> file descriptor for messages [2=stderr]\n"
-" --logfile=<file> log messages to <file>.pid<pid>\n"
-" --logsocket=ipaddr:port log messages to socket ipaddr:port\n"
+" --log-fd=<number> log messages to file descriptor [2=stderr]\n"
+" --log-file=<file> log messages to <file>.pid<pid>\n"
+" --log-socket=ipaddr:port log messages to socket ipaddr:port\n"
" --demangle=no|yes automatically demangle C++ names? [yes]\n"
" --num-callers=<number> show <num> callers in stack traces [4]\n"
@@ -1648,10 +1647,10 @@ static void process_cmd_line_options
( UInt* client_auxv, Addr esp_at_startup, const char* toolname )
{
- Int i, eventually_logfile_fd;
+ Int i, eventually_log_fd;
Int *auxp;
Int toolname_len = VG_(strlen)(toolname);
/* log to stderr by default, but usage message goes to stdout */
- eventually_logfile_fd = 2;
+ eventually_log_fd = 2;
/* Check for sane path in ./configure --prefix=... */
@@ -1749,18 +1748,34 @@ static void process_cmd_line_options
VG_DEEPEST_BACKTRACE)
+ // for backwards compatibility, replaced by --log-fd
else if (VG_CLO_STREQN(13, arg, "--logfile-fd=")) {
VG_(clo_log_to) = VgLogTo_Fd;
- VG_(clo_logfile_name) = NULL;
- eventually_logfile_fd = (Int)VG_(atoll)(&arg[13]);
+ VG_(clo_log_name) = NULL;
+ eventually_log_fd = (Int)VG_(atoll)(&arg[13]);
+ }
+ else if (VG_CLO_STREQN(9, arg, "--log-fd=")) {
+ VG_(clo_log_to) = VgLogTo_Fd;
+ VG_(clo_log_name) = NULL;
+ eventually_log_fd = (Int)VG_(atoll)(&arg[9]);
}
+ // for backwards compatibility, replaced by --log-file
else if (VG_CLO_STREQN(10, arg, "--logfile=")) {
VG_(clo_log_to) = VgLogTo_File;
- VG_(clo_logfile_name) = &arg[10];
+ VG_(clo_log_name) = &arg[10];
+ }
+ else if (VG_CLO_STREQN(11, arg, "--log-file=")) {
+ VG_(clo_log_to) = VgLogTo_File;
+ VG_(clo_log_name) = &arg[11];
}
+ // for backwards compatibility, replaced by --log-socket
else if (VG_CLO_STREQN(12, arg, "--logsocket=")) {
VG_(clo_log_to) = VgLogTo_Socket;
- VG_(clo_logfile_name) = &arg[12];
+ VG_(clo_log_name) = &arg[12];
+ }
+ else if (VG_CLO_STREQN(13, arg, "--log-socket=")) {
+ VG_(clo_log_to) = VgLogTo_Socket;
+ VG_(clo_log_name) = &arg[13];
}
@@ -1824,5 +1839,5 @@ static void process_cmd_line_options
}
- /* Set up logging now. After this is done, VG_(clo_logfile_fd)
+ /* Set up logging now. After this is done, VG_(clo_log_fd)
should be connected to whatever sink has been selected, and we
indiscriminately chuck stuff into it without worrying what the
@@ -1832,5 +1847,5 @@ static void process_cmd_line_options
the terminal any problems to do with processing command line
opts. */
- vg_assert(VG_(clo_logfile_fd) == 1 /* stdout */);
+ vg_assert(VG_(clo_log_fd) == 1 /* stdout */);
vg_assert(VG_(logging_to_filedes) == True);
@@ -1838,6 +1853,6 @@ static void process_cmd_line_options
case VgLogTo_Fd:
- vg_assert(VG_(clo_logfile_name) == NULL);
- VG_(clo_logfile_fd) = eventually_logfile_fd;
+ vg_assert(VG_(clo_log_name) == NULL);
+ VG_(clo_log_fd) = eventually_log_fd;
break;
@@ -1847,30 +1862,30 @@ static void process_cmd_line_options
Int pid = VG_(getpid)();
- vg_assert(VG_(clo_logfile_name) != NULL);
- vg_assert(VG_(strlen)(VG_(clo_logfile_name)) <= 900); /* paranoia */
+ vg_assert(VG_(clo_log_name) != NULL);
+ vg_assert(VG_(strlen)(VG_(clo_log_name)) <= 900); /* paranoia */
for (;;) {
if (seq == 0)
VG_(sprintf)(logfilename, "%s.pid%d",
- VG_(clo_logfile_name), pid );
+ VG_(clo_log_name), pid );
else
VG_(sprintf)(logfilename, "%s.pid%d.%d",
- VG_(clo_logfile_name), pid, seq );
+ VG_(clo_log_name), pid, seq );
seq++;
- eventually_logfile_fd
+ eventually_log_fd
= VG_(open)(logfilename,
VKI_O_CREAT|VKI_O_WRONLY|VKI_O_EXCL|VKI_O_TRUNC,
VKI_S_IRUSR|VKI_S_IWUSR);
- if (eventually_logfile_fd >= 0) {
- VG_(clo_logfile_fd) = VG_(safe_fd)(eventually_logfile_fd);
+ if (eventually_log_fd >= 0) {
+ VG_(clo_log_fd) = VG_(safe_fd)(eventually_log_fd);
break;
} else {
- if (eventually_logfile_fd != -VKI_EEXIST) {
+ if (eventually_log_fd != -VKI_EEXIST) {
VG_(message)(Vg_UserMsg,
"Can't create/open log file `%s.pid%d'; giving up!",
- VG_(clo_logfile_name), pid);
+ VG_(clo_log_name), pid);
VG_(bad_option)(
- "--logfile=<file> didn't work out for some reason.");
+ "--log-file=<file> didn't work out for some reason.");
break;
}
@@ -1881,20 +1896,19 @@ static void process_cmd_line_options
case VgLogTo_Socket: {
- vg_assert(VG_(clo_logfile_name) != NULL);
- vg_assert(VG_(strlen)(VG_(clo_logfile_name)) <= 900); /* paranoia */
- eventually_logfile_fd
- = VG_(connect_via_socket)( VG_(clo_logfile_name) );
- if (eventually_logfile_fd == -1) {
+ vg_assert(VG_(clo_log_name) != NULL);
+ vg_assert(VG_(strlen)(VG_(clo_log_name)) <= 900); /* paranoia */
+ eventually_log_fd = VG_(connect_via_socket)( VG_(clo_log_name) );
+ if (eventually_log_fd == -1) {
VG_(message)(Vg_UserMsg,
- "Invalid --logsocket=ipaddr or --logsocket=ipaddr:port spec");
+ "Invalid --log-socket=ipaddr or --log-socket=ipaddr:port spec");
VG_(message)(Vg_UserMsg,
- "of `%s'; giving up!", VG_(clo_logfile_name) );
+ "of `%s'; giving up!", VG_(clo_log_name) );
VG_(bad_option)(
- "--logsocket=");
+ "--log-socket=");
}
- if (eventually_logfile_fd == -2) {
+ if (eventually_log_fd == -2) {
VG_(message)(Vg_UserMsg,
"valgrind: failed to connect to logging server `%s'.",
- VG_(clo_logfile_name) );
+ VG_(clo_log_name) );
VG_(message)(Vg_UserMsg,
"Log messages will sent to stderr instead." );
@@ -1903,6 +1917,6 @@ static void process_cmd_line_options
/* We don't change anything here. */
} else {
- vg_assert(eventually_logfile_fd > 0);
- VG_(clo_logfile_fd) = eventually_logfile_fd;
+ vg_assert(eventually_log_fd > 0);
+ VG_(clo_log_fd) = eventually_log_fd;
VG_(logging_to_filedes) = False;
}
@@ -1912,11 +1926,11 @@ static void process_cmd_line_options
}
- /* Move logfile_fd into the safe range, so it doesn't conflict with any app fds */
- eventually_logfile_fd = VG_(fcntl)(VG_(clo_logfile_fd), VKI_F_DUPFD, VG_(max_fd)+1);
- if (eventually_logfile_fd < 0)
+ /* Move log_fd into the safe range, so it doesn't conflict with any app fds */
+ eventually_log_fd = VG_(fcntl)(VG_(clo_log_fd), VKI_F_DUPFD, VG_(max_fd)+1);
+ if (eventually_log_fd < 0)
VG_(message)(Vg_UserMsg, "valgrind: failed to move logfile fd into safe range");
else {
- VG_(clo_logfile_fd) = eventually_logfile_fd;
- VG_(fcntl)(VG_(clo_logfile_fd), VKI_F_SETFD, VKI_FD_CLOEXEC);
+ VG_(clo_log_fd) = eventually_log_fd;
+ VG_(fcntl)(VG_(clo_log_fd), VKI_F_SETFD, VKI_FD_CLOEXEC);
}
--- valgrind/coregrind/vg_messages.c #1.9:1.10
@@ -98,5 +98,5 @@ int VG_(end_msg) ( void )
{
int count = 0;
- if (VG_(clo_logfile_fd) >= 0) {
+ if (VG_(clo_log_fd) >= 0) {
add_to_buf('\n');
VG_(send_bytes_to_logging_sink) (
@@ -113,7 +113,7 @@ void VG_(send_bytes_to_logging_sink) ( C
Int rc;
if (VG_(logging_to_filedes)) {
- VG_(write)( VG_(clo_logfile_fd), msg, nbytes );
+ VG_(write)( VG_(clo_log_fd), msg, nbytes );
} else {
- rc = VG_(write_socket)( VG_(clo_logfile_fd), msg, nbytes );
+ rc = VG_(write_socket)( VG_(clo_log_fd), msg, nbytes );
if (rc == -1) {
/* for example, the listener process died. Switch back to
@@ -121,6 +121,6 @@ void VG_(send_bytes_to_logging_sink) ( C
VG_(logging_to_filedes) = True;
VG_(clo_log_to) = VgLogTo_Fd;
- VG_(clo_logfile_fd) = 2;
- VG_(write)( VG_(clo_logfile_fd), msg, nbytes );
+ VG_(clo_log_fd) = 2;
+ VG_(write)( VG_(clo_log_fd), msg, nbytes );
}
}
--- valgrind/coregrind/vg_mylibc.c #1.72:1.73
@@ -701,5 +701,5 @@ static void add_to_myprintf_buf ( Char c
{
if (n_myprintf_buf >= 100-10 /*paranoia*/ ) {
- if (VG_(clo_logfile_fd) >= 0) {
+ if (VG_(clo_log_fd) >= 0) {
VG_(send_bytes_to_logging_sink)(
myprintf_buf, VG_(strlen)(myprintf_buf) );
@@ -722,5 +722,5 @@ UInt VG_(printf) ( const char *format, .
ret = VG_(vprintf) ( add_to_myprintf_buf, format, vargs );
- if (n_myprintf_buf > 0 && VG_(clo_logfile_fd) >= 0) {
+ if (n_myprintf_buf > 0 && VG_(clo_log_fd) >= 0) {
VG_(send_bytes_to_logging_sink)( myprintf_buf, n_myprintf_buf );
}
--- valgrind/coregrind/vg_signals.c #1.69:1.70
@@ -1556,7 +1556,7 @@ static void make_coredump(ThreadId tid,
struct elf_prstatus prstatus;
- if (VG_(clo_logfile_name) != NULL) {
+ if (VG_(clo_log_name) != NULL) {
coreext = ".core";
- basename = VG_(clo_logfile_name);
+ basename = VG_(clo_log_name);
}
--- valgrind/coregrind/vg_syscalls.c #1.101:1.102
@@ -1058,12 +1058,11 @@ static Addr do_brk(Addr newbrk)
static Bool fd_allowed(Int fd, const Char *syscall, ThreadId tid)
{
- if (fd < 0 || fd > VG_(max_fd) || fd == VG_(clo_logfile_fd)) {
+ if (fd < 0 || fd > VG_(max_fd) || fd == VG_(clo_log_fd)) {
VG_(message)(Vg_UserMsg,
"Warning: invalid file descriptor %d in syscall %s()",
fd, syscall);
- if (fd == VG_(clo_logfile_fd))
+ if (fd == VG_(clo_log_fd))
VG_(message)(Vg_UserMsg,
- " Use --logfile-fd=<number> to select an alternative "
- "logfile fd.");
+ " Use --log-fd=<number> to select an alternative log fd.");
if (VG_(clo_verbosity) > 1) {
ExeContext *ec = VG_(get_ExeContext)(tid);
@@ -2100,6 +2099,5 @@ PRE(close)
/* int close(int fd); */
MAYBE_PRINTF("close ( %d )\n",arg1);
- /* Detect and negate attempts by the client to close Valgrind's
- logfile fd ... */
+ /* Detect and negate attempts by the client to close Valgrind's log fd */
if (!fd_allowed(arg1, "close", tid))
res = -VKI_EBADF;
--- valgrind/coregrind/docs/coregrind_core.html #1.29:1.30
@@ -163,8 +163,8 @@
commentary to the standard error stream. If you want to send
it to some other file descriptor, for example number 9,
- you can specify <code>--logfile-fd=9</code>.
+ you can specify <code>--log-fd=9</code>.
<p>
<li>A less intrusive option is to write the commentary to a file,
- which you specify by <code>--logfile=filename</code>. Note
+ which you specify by <code>--log-file=filename</code>. Note
carefully that the commentary is <b>not</b> written to the file
you specify, but instead to one called
@@ -177,8 +177,8 @@
<li>The least intrusive option is to send the commentary to a network
socket. The socket is specified as an IP address and port number
- pair, like this: <code>--logsocket=192.168.0.1:12345</code> if you
+ pair, like this: <code>--log-socket=192.168.0.1:12345</code> if you
want to send the output to host IP 192.168.0.1 port 12345 (I have
no idea if 12345 is a port of pre-existing significance). You can
- also omit the port number: <code>--logsocket=192.168.0.1</code>,
+ also omit the port number: <code>--log-socket=192.168.0.1</code>,
in which case a default port of 1500 is used. This default is
defined by the constant <code>VG_CLO_DEFAULT_LOGPORT</code>
@@ -210,5 +210,5 @@
the default (1500). The specified port must be in the range
1024 to 65535. The same restriction applies to port numbers
- specified by a <code>--logsocket=</code> to Valgrind itself.
+ specified by a <code>--log-socket=</code> to Valgrind itself.
</ul>
<p>
@@ -228,5 +228,5 @@
if the tool does profiling, the profile data will be written to a file
of some kind, depending on the tool, and independent of what
-<code>--log*</code> options are in force. The commentary is intended
+<code>--log-*</code> options are in force. The commentary is intended
to be a low-bandwidth, human-readable channel. Profiling data, on the
other hand, is usually voluminous and not meaningful without further
@@ -527,5 +527,5 @@
</li><br><p>
- <li><code>--logfile-fd=<number></code> [default: 2, stderr]
+ <li><code>--log-fd=<number></code> [default: 2, stderr]
<p>Specifies that Valgrind should send all of its
messages to the specified file descriptor. The default, 2, is
@@ -534,5 +534,5 @@
</li><br><p>
- <li><code>--logfile=<filename></code>
+ <li><code>--log-file=<filename></code>
<p>Specifies that Valgrind should send all of its
messages to the specified file. In fact, the file name used
@@ -542,5 +542,5 @@
</li><br><p>
- <li><code>--logsocket=<ip-address:port-number></code>
+ <li><code>--log-socket=<ip-address:port-number></code>
<p>Specifies that Valgrind should send all of its messages to
the specified port at the specified IP address. The port may be
@@ -966,5 +966,5 @@
<li><code>VALGRIND_COUNT_ERRORS</code>: returns the number of errors
found so far by Valgrind. Can be useful in test harness code when
- combined with the <code>--logfile-fd=-1</code> option; this runs
+ combined with the <code>--log-fd=-1</code> option; this runs
Valgrind silently, but the client program can detect when errors
occur. Only useful for tools that report errors, e.g. it's useful for
@@ -1502,5 +1502,5 @@
to close the logfile, because you'd never see any diagnostic
information after that point. If you see this message,
- you may want to use the <code>--logfile-fd=<number></code>
+ you may want to use the <code>--log-fd=<number></code>
option to specify a different logfile file-descriptor number.
Or
--- valgrind/include/vg_skin.h.base #1.20:1.21
@@ -383,6 +383,6 @@
*
* Note that they all output to the file descriptor given by the
- * --logfile-fd=N argument, which defaults to 2 (stderr). Hence no
- * need for VG_(fprintf)().
+ * --log-fd/--log-file/--log-socket argument, which defaults to 2 (stderr).
+ * Hence no need for VG_(fprintf)().
*/
extern UInt VG_(printf) ( const char *format, ... );
--- valgrind/memcheck/tests/error_counts.vgtest #1.1:1.2
@@ -1,2 +1,2 @@
-vgopts: --logfile-fd=-1
+vgopts: --log-fd=-1
prog: error_counts
--- valgrind/none/tests/cmdline1.stdout.exp #1.3:1.4
@@ -25,7 +25,7 @@
user options for Valgrind tools that report errors:
- --logfile-fd=<number> file descriptor for messages [2=stderr]
- --logfile=<file> log messages to <file>.pid<pid>
- --logsocket=ipaddr:port log messages to socket ipaddr:port
+ --log-fd=<number> log messages to file descriptor [2=stderr]
+ --log-file=<file> log messages to <file>.pid<pid>
+ --log-socket=ipaddr:port log messages to socket ipaddr:port
--demangle=no|yes automatically demangle C++ names? [yes]
--num-callers=<number> show <num> callers in stack traces [4]
--- valgrind/none/tests/cmdline2.stdout.exp #1.3:1.4
@@ -25,7 +25,7 @@
user options for Valgrind tools that report errors:
- --logfile-fd=<number> file descriptor for messages [2=stderr]
- --logfile=<file> log messages to <file>.pid<pid>
- --logsocket=ipaddr:port log messages to socket ipaddr:port
+ --log-fd=<number> log messages to file descriptor [2=stderr]
+ --log-file=<file> log messages to <file>.pid<pid>
+ --log-socket=ipaddr:port log messages to socket ipaddr:port
--demangle=no|yes automatically demangle C++ names? [yes]
--num-callers=<number> show <num> callers in stack traces [4]
|
|
From: Nicholas N. <nj...@ca...> - 2004-06-21 11:37:10
|
On Wed, 9 Jun 2004, Paul Mackerras wrote: > I do need to get in and implement the string load/store instructions. > I have avoided them so far because I haven't hit the problem myself, and > because doing lswx/stswx is going to be a bit interesting - uCode > doesn't have a way to express loading a variable number of registers > based on the contents of another register (XER). Sounds similar to the REP prefixed x86 instructions, which are done with a JIFZ loop. N |
|
From: Jeremy F. <je...@go...> - 2004-06-21 10:52:51
|
On Sun, 2004-06-20 at 06:29, Tom Hughes wrote: > I assume that the proxy LWP code should ignore attempts by the application > to block SIGVGINT in the same way that it does for SIGVGKILL but I guess > that Jeremy is probably best placed to know the right fix. That sounds right - the app shouldn't be able to touch those two. J |
|
From: Nicholas N. <nj...@ca...> - 2004-06-21 10:15:54
|
Josef, I've finally (it only took 6 months!) had a close look at your description of how Calltree accurately tracks function entry/exit. I've paraphrased your description to help me understand it better, but I'm still not quite clear on some points. I looked at the code, but found it hard to understand. Could you help me? I've written my questions in square brackets. Here's the description. -------- Data structures: - have a shadow call stack for every thread [not sure exactly what goes on this] Action at BB start -- depends on jmp_kind from previous BB: - If jmp_kind is neither JmpCall nor JmpRet (ie. is JmpNone, JmpBoring, JmpCond or JmpSyscall) and we transferred from one ELF object/section to another, it must be a function call to a shared library -- treat as a call. This catches jmps from PLT code. - If this is the first BB of a function, treat as a call. This catches tail calls (which gcc uses for "return f()" with -O2). [What if a function had a 'goto' back to its beginning? Would that be interpreted as a call?] - Unwind the shadow call stack if necessary. [when is "necessary"? If the real %esp > the shadow stack %esp?] - If this is a function return and there was no shadow stack unwinding, this must be a RET control transfer (typically used in the runtime linker). Pop the shadow call stack, setting the previous BB address to call site and override jmpkind with a CALL. By this, you get 2 function calls from a calling site. [I don't understand this... What is a "RET control transfer"? Why do you end up with 2 function calls -- is that a bad thing?] - If we're treating the control transfer as a call, push new function call from previous BB to current BB on shadow call stack. [when is this information used?] - Save current BB address to be available for call to handler in next BB. Other actions: When entering a signal handler, first push a separation marker on the thread's shadow stack, then use it as normal. The marker is used for unwinding when leaving the signal handler. This is fine as there is no scheduling among signal handlers of one thread. Special care is needed at thread switches and enter/leave of signal handlers, as we need separate shadow call stacks. [Do you mean "separate shadow call stacks for each thread"?] Known bugs: - should check if unwinding is necessary when ESP is explicitly written to. -------- What about stack switching -- does it cope with that? (Not that Valgrind in general does...) N |
|
From: Tom H. <th...@cy...> - 2004-06-21 07:18:27
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-06-21 03:10:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in cachegrind/tests ---------------------------------- -- Running tests in corecheck/tests ----------------------------------- as_mmap: valgrind ./as_mmap as_shm: valgrind ./as_shm erringfds: valgrind ./erringfds fdleak_cmsg: valgrind --track-fds=yes ./fdleak_cmsg < /dev/null fdleak_creat: valgrind --track-fds=yes ./fdleak_creat < /dev/null fdleak_dup: valgrind --track-fds=yes ./fdleak_dup < /dev/null fdleak_dup2: valgrind --track-fds=yes ./fdleak_dup2 < /dev/null fdleak_fcntl: valgrind --track-fds=yes ./fdleak_fcntl < /dev/null fdleak_ipv4: valgrind --track-fds=yes ./fdleak_ipv4 < /dev/null fdleak_open: valgrind --track-fds=yes ./fdleak_open < /dev/null fdleak_pipe: valgrind --track-fds=yes ./fdleak_pipe < /dev/null fdleak_socketpair: valgrind --track-fds=yes ./fdleak_socketpair < /dev/null pth_atfork1: valgrind ./pth_atfork1 pth_cancel1: valgrind ./pth_cancel1 *** pth_cancel1 failed (stdout) *** File pth_cancel2.vgtest not openable *** pth_cancel1 failed (stderr) *** make: *** [regtest] Error 2 |
|
From: Tom H. <to...@co...> - 2004-06-21 02:25:01
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-06-21 03:20: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 ---------------------------------------- == 168 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-06-21 02:19:18
|
Nightly build on audi ( Red Hat 9 ) started at 2004-06-21 03:15: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 ---------------------------------------- == 168 tests, 7 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) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-06-21 02:08:16
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-06-21 03:05:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow 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, 8 stderr failures, 1 stdout failure ================= helgrind/tests/deadlock (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/badfree-2trace (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/new_nothrow (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-06-21 02:06:57
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-06-21 03:00:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow readline1: valgrind ./readline1 resolv: valgrind ./resolv 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 ---------------------------------------- == 168 tests, 1 stderr failure, 0 stdout failures ================= memcheck/tests/badfree-2trace (stderr) make: *** [regtest] Error 1 |