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
(15) |
2
(17) |
3
(23) |
4
(13) |
5
(7) |
6
(8) |
7
(9) |
|
8
(8) |
9
(31) |
10
(31) |
11
(19) |
12
(11) |
13
(38) |
14
(14) |
|
15
(8) |
16
(11) |
17
(7) |
18
(17) |
19
(12) |
20
(12) |
21
(17) |
|
22
(19) |
23
(33) |
24
(42) |
25
(37) |
26
(23) |
27
(27) |
28
(27) |
|
29
(16) |
30
(52) |
31
(33) |
|
|
|
|
|
From: Jeremy F. <je...@go...> - 2004-08-27 23:39:18
|
On Fri, 2004-08-27 at 18:12 -0500, Bob Friesenhahn wrote: > Ok. The gdb server stub will need to be able to start/stop execution > of the rest of the program while still being able to send responses to > GDB and accept commands from GDB. I am not sure how to do this from > within the context of a Unix process. Normally SIGSTOP would stop all > threads in the process. It seems to me that another process is > necessary in order to provide the external control. Valgrind is essentially single-threaded internally, so if the gdb stub is running out of the scheduler thread, then nothing else is going on while it runs. I don't think any other processes would help at all. J |
|
From: Bob F. <bfr...@si...> - 2004-08-27 23:12:25
|
On Fri, 27 Aug 2004, Jeremy Fitzhardinge wrote: > On Fri, 2004-08-27 at 16:04 -0500, Bob Friesenhahn wrote: >> The two schemes are quite different. Ptrace is a way to control a >> subordinate process and get/set data to/from it. > > I think Chris understands that - he's just proposing an internal API, > which is somewhat analogous to the ptrace syscall, to give the gdb > server stub access to the per-thread virtual machine state. Ok. The gdb server stub will need to be able to start/stop execution of the rest of the program while still being able to send responses to GDB and accept commands from GDB. I am not sure how to do this from within the context of a Unix process. Normally SIGSTOP would stop all threads in the process. It seems to me that another process is necessary in order to provide the external control. Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
|
From: Jeremy F. <je...@go...> - 2004-08-27 22:01:47
|
On Fri, 2004-08-27 at 12:13 -0700, Robert Walsh wrote: > Idle thought: could we provide a malloc (and friends) that libc could > use, that's just a wrapper around out VG_(malloc) stuff? That way we > could use lots of goodies from libc, like printf, the resolver code, > etc. Very tricky, because glibc has all that nasty short-circuiting machinery. Calls internal to glibc don't use the normal dynamic linker name resolution rules, so you can't override calls to malloc, etc. Or you can override some calls, but not all... J |
|
From: Jeremy F. <je...@go...> - 2004-08-27 21:58:37
|
On Fri, 2004-08-27 at 16:04 -0500, Bob Friesenhahn wrote: > The two schemes are quite different. Ptrace is a way to control a > subordinate process and get/set data to/from it. I think Chris understands that - he's just proposing an internal API, which is somewhat analogous to the ptrace syscall, to give the gdb server stub access to the per-thread virtual machine state. I don't think ptrace is a particularly good model though. Since the gdbserver will be in the same address space as the client, it can just directly access memory. For thread state, we can do something simple to allow read/modify access to the register state, and to control the thread's execution. There are some interesting questions to resolve though, since we also have Tool metadata associated with all the VM state. Should we (can we?) expose that to GDB, or just make things up when GDB modifies the state? J |
|
From: Jeremy F. <je...@go...> - 2004-08-27 21:55:33
|
On Fri, 2004-08-27 at 19:57 +1000, Paul Mackerras wrote: > Nicholas Nethercote writes: > > > That would be better, but Jeremy is of the opinion that loading PIC is (a) > > difficult and (b) platform-specific. My patch providing multiple versions > > of stage2 (which I posted earlier today) is a simple and not-too-bad > > alternative. > > Just today I learned that gcc-3.4 and later plus current binutils is > capable of producing position-independent executables, or PIE for > short. If you compile with -fpie and link with -Wl,-pie, the linker > will link the executable with base address 0 and include all the > relocations needed to run the executable at any address. What's more, > ld.so takes care of doing all the relocations for you. If this is stage2's ld.so, then that should work nicely. J |
|
From: Bob F. <bfr...@si...> - 2004-08-27 21:04:35
|
On Fri, 27 Aug 2004, Chris January wrote: > >>> After careful thought I have come up with another design >> which I think >>> is more satisfactory. The basic idea is to write a function called >>> VG_(ptrace) which would have ptrace-like functionality, >> i.e. it would >>> give access to the simulated state of Valgrind's threads, >> etc. Then we >>> link in GDB's remote debugging server with Valgrind, >> porting it to the >>> new ptrace function. >> >> Why not just get VG to implement GDB's remote debugging >> protocol directly? It's quite simple, and the protocol has >> been stable for a long time. That way, you don't have to >> modify GDB at all. This is doubly desirable since GDB >> evolves at a glacial pace. > > That was what I proposed however to keep the GDB debugging protocol server > separate I suggested a VG_(ptrace) function which exposed all the > functionality required to support it. The two schemes are quite different. Ptrace is a way to control a subordinate process and get/set data to/from it. Ptrace is pretty gross, and requires the debugger to be aware of the memory layout (which is tweaked to non-standard configurations by valgrind). It is highly likely that GDB uses alternate means to access the process address space besides ptraces's primitive access, which would make it very difficult for valgrind to "virtualize" the process. I don't think that emulating "ptrace" makes much sense for valgrind. If valgrind implements the remote debugging protocol "directly" as would be done for an embedded environment, then the process would need to control itself. Valgrind's stub would need to virtualize the environment so that GDB thinks that it is debugging a normal OS application. The big question is if a Unix process is able to provide the control necessary to properly support a debugging stub. A third possibility is to implement a modified gdbserver which knows about valgrind so that it can use the existing Linux ptrace to control the process, but virtualize the process footprint so GDB itself doesn't need to be modified. GDB <---> <-- vgdbserver --> valgrind/process Bob ====================================== Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
|
From: Chris J. <ch...@at...> - 2004-08-27 20:01:27
|
> > After careful thought I have come up with another design > which I think > > is more satisfactory. The basic idea is to write a function called > > VG_(ptrace) which would have ptrace-like functionality, > i.e. it would > > give access to the simulated state of Valgrind's threads, > etc. Then we > > link in GDB's remote debugging server with Valgrind, > porting it to the > > new ptrace function. > > Why not just get VG to implement GDB's remote debugging > protocol directly? It's quite simple, and the protocol has > been stable for a long time. That way, you don't have to > modify GDB at all. This is doubly desirable since GDB > evolves at a glacial pace. That was what I proposed however to keep the GDB debugging protocol server separate I suggested a VG_(ptrace) function which exposed all the functionality required to support it. Chris |
|
From: Robert W. <rj...@du...> - 2004-08-27 19:13:58
|
> I get these compile warnings: >=20 > vg_mylibc.c: In function `vgPlain_system': > vg_mylibc.c:1562: warning: passing arg 2 of `execve' from incompatible = pointer type > vg_mylibc.c:1562: warning: passing arg 3 of `execve' from incompatible = pointer type I couldn't figure these out right away, so I ignored them :-) They seem harmless - probably something to do with const. I'll look into it some other time. > vg_syscalls.c: In function `after_kill': > vg_syscalls.c:4007: warning: implicit declaration of function `getpgrp' Oops - I left out a header file. I will update the patch tonight. > But I'm wary of doing this in an ad-hoc way... what restrictions do we=20 > have on using libc? I think we can't use any functions that could use > brk, ie. any functions that use malloc(). Is that right? How do we know= =20 > which functions satisfy that condition? I think so. Right now, I've changed only functions that I know are trivial (i.e. foo() being essentially just a wrapper for syscall(FOO) style functions.) This means getpid() doesn't work, for example, as it appears to do some caching of the pid, which I assume fork() invalidates somehow. Idle thought: could we provide a malloc (and friends) that libc could use, that's just a wrapper around out VG_(malloc) stuff? That way we could use lots of goodies from libc, like printf, the resolver code, etc. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Eric E. <eri...@fr...> - 2004-08-27 16:48:02
|
Nicholas Nethercote wrote: > On Thu, 26 Aug 2004, Eric Estievenart wrote: > >> For the patch, indeed I stripped it a lot, and can't see how I could >> make it smaller without: >> - loosing vital informations for valgui >> - duplicating current code >> - risking regressions compared to current patch > > Can you explain this more -- what information do you lose, what code is > duplicated? I don't understand the bit about regressions. Basically, loosing: - module name when there are debug infos prevents from categorizing the modules. So error identification can't be done properly, or changes depending of the presence of debug libs or not when running - full source names will be a pain for the user - Small bit sof useful info, like pid relationship in parent (not in child), process exit status makes things weird to understand when tracing a process and its children The patch addresses these issues properly. One question was about making it less intrusive, but it can't be done without risking to loose these infos it generates, or duplicating the old code and tweaking it. For now there is no code duplication, and I'm fine with the patch. For the regressions, I meant that the patch, as it is, seems to work correctly, and changing it more could lead to regressions. > What changes to the logging interface are you thinking of? I'll go on that topic later, sorry I'm a bit in a hurry... BTW there is no urgency. Cheers -- Eric |
|
From: Bryan O'S. <bo...@se...> - 2004-08-27 16:42:24
|
On Fri, 2004-08-27 at 09:10 +0100, Chris January wrote: > After careful thought I have come up with another design which I think is > more satisfactory. The basic idea is to write a function called VG_(ptrace) > which would have ptrace-like functionality, i.e. it would give access to the > simulated state of Valgrind's threads, etc. Then we link in GDB's remote > debugging server with Valgrind, porting it to the new ptrace function. Why not just get VG to implement GDB's remote debugging protocol directly? It's quite simple, and the protocol has been stable for a long time. That way, you don't have to modify GDB at all. This is doubly desirable since GDB evolves at a glacial pace. <b |
|
From: Nicholas N. <nj...@ca...> - 2004-08-27 16:19:48
|
On Thu, 26 Aug 2004, Robert Walsh wrote: > Now that we've got FV, I've started removing things from vg_mylibc.c and > replacing calls to them with just regular libc calls. Totally > experimental - I just want to see how far I can go with this. The patch > against the CVS head is at: > > http://www.durables.org/software/valgrind > > No regressions on my Fedora Core 2 box so far. If someone could apply > the patch and test it on other distros, I'd appreciate it. I get these compile warnings: vg_mylibc.c: In function `vgPlain_system': vg_mylibc.c:1562: warning: passing arg 2 of `execve' from incompatible pointer type vg_mylibc.c:1562: warning: passing arg 3 of `execve' from incompatible pointer type vg_syscalls.c: In function `after_kill': vg_syscalls.c:4007: warning: implicit declaration of function `getpgrp' No regressions. I appreciate the amount of crap this patch cuts -- 237 lines' worth. But I'm wary of doing this in an ad-hoc way... what restrictions do we have on using libc? I think we can't use any functions that could use brk, ie. any functions that use malloc(). Is that right? How do we know which functions satisfy that condition? N |
|
From: Nicholas N. <nj...@ca...> - 2004-08-27 16:03:47
|
On Thu, 26 Aug 2004, Eric Estievenart wrote: > For the patch, indeed I stripped it a lot, and can't see how I could > make it smaller without: > - loosing vital informations for valgui > - duplicating current code > - risking regressions compared to current patch Can you explain this more -- what information do you lose, what code is duplicated? I don't understand the bit about regressions. > For a more general change, I would be happy to do anything in the > future, mostly concerning the logging interface, but I think > it is completely out-of-plan for 2.2.0. What changes to the logging interface are you thinking of? N |
|
From: Nicholas N. <nj...@ca...> - 2004-08-27 11:29:15
|
On Fri, 27 Aug 2004, Paul Mackerras wrote: > We could test for PIE support in configure.in and use it if present, > otherwise link at a fixed address like we do at the moment. Indeed, that sounds like a pretty good solution. N |
|
From: Paul M. <pa...@sa...> - 2004-08-27 11:20:23
|
Correcting myself... > If you compile with -fpie and link with -Wl,-pie, the linker > will link the executable with base address 0 and include all the > relocations needed to run the executable at any address. What's more, > ld.so takes care of doing all the relocations for you. In fact the correct switch for linking is -pie. It seems you still need -fpie for compiling, although I would have expected -pie to imply -fpie. Paul. |
|
From: Paul M. <pa...@sa...> - 2004-08-27 10:56:10
|
Tom Hughes writes: > In message <166...@ca...> > Paul Mackerras <pa...@sa...> wrote: > > > Just today I learned that gcc-3.4 and later plus current binutils is > > capable of producing position-independent executables, or PIE for > > short. If you compile with -fpie and link with -Wl,-pie, the linker > > will link the executable with base address 0 and include all the > > relocations needed to run the executable at any address. What's more, > > ld.so takes care of doing all the relocations for you. > > My Fedora Core 2 box claims to support PIE in gcc and it only > has version 3.3.3. That's great. In fact my resident toolchain expert tells me that using -fpic for the .c -> .o step will also work (the difference is that -fpic means that the compiler can't assume that calls to non-static functions are local). So the main constraint is whether the linker has PIE support. It looks like the PIE binutils support went in in June 2003. We could test for PIE support in configure.in and use it if present, otherwise link at a fixed address like we do at the moment. Paul. |
|
From: Tom H. <th...@cy...> - 2004-08-27 10:27:27
|
In message <166...@ca...>
Paul Mackerras <pa...@sa...> wrote:
> Just today I learned that gcc-3.4 and later plus current binutils is
> capable of producing position-independent executables, or PIE for
> short. If you compile with -fpie and link with -Wl,-pie, the linker
> will link the executable with base address 0 and include all the
> relocations needed to run the executable at any address. What's more,
> ld.so takes care of doing all the relocations for you.
My Fedora Core 2 box claims to support PIE in gcc and it only
has version 3.3.3.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Paul M. <pa...@sa...> - 2004-08-27 09:57:20
|
Nicholas Nethercote writes:
> That would be better, but Jeremy is of the opinion that loading PIC is (a)
> difficult and (b) platform-specific. My patch providing multiple versions
> of stage2 (which I posted earlier today) is a simple and not-too-bad
> alternative.
Just today I learned that gcc-3.4 and later plus current binutils is
capable of producing position-independent executables, or PIE for
short. If you compile with -fpie and link with -Wl,-pie, the linker
will link the executable with base address 0 and include all the
relocations needed to run the executable at any address. What's more,
ld.so takes care of doing all the relocations for you.
I tried this out with a little hello world program and a slightly
modified version of stage1.c and ume.c. All that I had to change was
to add the base address where I wanted the executable loaded to the
value of e->e.e_entry and the PT_PHDR ph->p_vaddr value. The patch
below shows exactly what I had to change. In the patch I use the
constant 0x60000000 but of course for Valgrind we would choose that
value based on the stack address or something similar.
This works on x86 and almost works on PPC (modulo some bugs in ld.so
and the gcc compiler driver that can be worked around). The only
downside is the need to use gcc-3.4 or later.
Paul.
diff -urN ume.c ume-pie.c
--- ume.c 2004-08-18 23:08:59.000000000 +1000
+++ ume-pie.c 2004-08-27 15:31:54.000000000 +1000
@@ -423,6 +423,7 @@
ESZ(Word) interp_align = VKI_BYTES_PER_PAGE;
int i;
void *entry;
+ ESZ(Addr) exebase = 0x60000000;
e = readelf(fd, name);
@@ -430,14 +431,14 @@
return ENOEXEC;
info->phnum = e->e.e_phnum;
- info->entry = e->e.e_entry;
+ info->entry = e->e.e_entry + exebase;
for(i = 0; i < e->e.e_phnum; i++) {
ESZ(Phdr) *ph = &e->p[i];
switch(ph->p_type) {
case PT_PHDR:
- info->phdr = ph->p_vaddr;
+ info->phdr = ph->p_vaddr + exebase;
break;
case PT_LOAD:
@@ -495,6 +496,7 @@
}
}
+#if 0
if (info->exe_base != info->exe_end) {
if (minaddr >= maxaddr ||
(minaddr < info->exe_base ||
@@ -506,8 +508,9 @@
return ENOMEM;
}
}
+#endif
- info->brkbase = mapelf(e, 0); /* map the executable */
+ info->brkbase = mapelf(e, exebase); /* map the executable */
if (info->brkbase == 0)
return ENOMEM;
|
|
From: Adun R. <adu...@ml...> - 2004-08-27 08:47:39
|
On Wed, 25 Aug 2004 04:07:22 +0200, "KJK::Hyperion" <no...@li...> said: > At 16.33 20/08/2004, you wrote: > >I see not difference between changing the IAT or placing Breakpoints > >inside the code of those functions. > > well, since we control the whole memory space and flow of control, we > don't > need to hook any function (we can just stop execution when the emulated > flow of control reaches certain points or instructions, like the system > call sequences), except the KiXxx callbacks. For those we need a > breakpoint, because we can't change their address and because they make > us > lose control of the program's flow, somewhat like signals on Linux We mean the same. > >I fail to see why not run the entire code in the client's process. > > because 1) we need full control on the program's flow, 2) it drastically > reduces the amount of context switches between client and Valgrind and 3) > it allows us to fully take advantage of the inter-process manipulation > features of Windows, which Valgrind would like to enjoy on Linux but > cannot. I'm still interested to hear about your idea of how Valgrind on > Windows would work, though - could you describe a "typical" session? > maybe > an example will help you clarify your ideas > I don't want context switches at all nor inter-process manipulation, though I would like to hear more from you, as this seems as a good solution as well. The valgrind's process starts the client's process in suspended mode. The next step is to we recompile the client's process code, so that we will be able to implant special code upon instruction such as sysenter or int 2Eh [This was already said by you and by me]. We will also capture setting the KiXXX call-backs and change that code to point to our own code. We will also add the entire profiling mechanism (Valgrind's features) into the code [we will also change the IAT of the client's process, so that for example, malloc will point to our code]. After all this is done, we take the entire compiled code. Copy it into the altered client's process, and start execution form there using SetThreadContext. The valgrind's process is irrelevant from this point onward. -- Adun R. adu...@ml... |
|
From: Oswald B. <os...@kd...> - 2004-08-27 08:31:02
|
On Fri, Aug 27, 2004 at 08:17:47AM +1000, Paul Mackerras wrote: > Nicholas Nethercote writes: > > One possibility is to look at the address of a stack variable, and > > round up a bit. This is really simple but assumes that the stack is > > at the top of the user-space. > > That is always true on Linux on all the architectures that Valgrind > has been ported to. :) Well, it's almost true, since we might have a > VDSO just above the stack, but it's true to say that we can't mmap > anything at any higher address than the stack. > it's been at least discussed to move the stack down; i think ingo (?) even had some patches in/for redhat already. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Chris J. <ch...@at...> - 2004-08-27 08:08:47
|
As some of you may know I developed a patch for Valgrind 2.0.0 that = allowed one to perform live debugging of programs running under Valgrind. = However the patch was never included in Valgrind CVS because the members of this list were unsure that using a shared memory region for to access the Valgrind's thread state was the best way to solve the problem. I agreed = with this analysis - exposing internal structures isn't future proof and also required changes to GDB. After careful thought I have come up with another design which I think = is more satisfactory. The basic idea is to write a function called = VG_(ptrace) which would have ptrace-like functionality, i.e. it would give access to = the simulated state of Valgrind's threads, etc. Then we link in GDB's remote debugging server with Valgrind, porting it to the new ptrace function. Valgrind processes will now be remote debugging targets for GDB. A small Valgrind target stub could be written for GDB which would launch and = connect to Valgrind processes transparently to hide the details of the mechanism from the users. Comments and criticism welcome. Regards, Chris January -- http://www.atomice.com |
|
From: Tom H. <th...@cy...> - 2004-08-27 03:14:09
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-08-27 03:00:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow error_counts: valgrind --log-fd=-1 ./error_counts errs1: valgrind -q ./errs1 execve: valgrind -q ./execve execve2: valgrind -q --trace-children=yes ./execve2 exitprog: valgrind -q ./exitprog fpeflags: valgrind -q ./fpeflags fprw: valgrind -q ./fprw fwrite: valgrind -q ./fwrite inits: valgrind -q ./inits inline: valgrind -q ./inline insn_basic: valgrind -q ./../../none/tests/insn_basic insn_cmov: valgrind -q ./../../none/tests/insn_cmov insn_fpu: valgrind -q ./../../none/tests/insn_fpu insn_mmx: valgrind -q ./../../none/tests/insn_mmx insn_mmxext: valgrind -q ./../../none/tests/insn_mmxext insn_sse: valgrind -q ./../../none/tests/insn_sse malloc1: valgrind -q ./malloc1 malloc2: valgrind -q ./malloc2 Could not read `malloc2.stderr.exp' make: *** [regtest] Error 2 |
|
From: <js...@ac...> - 2004-08-27 02:57:40
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2004-08-27 03:50:00 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 ---------------------------------------- == 174 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: Tom H. <to...@co...> - 2004-08-27 02:25:16
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-08-27 03:20: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 ---------------------------------------- == 179 tests, 8 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/execve2 (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-08-27 02:20:10
|
Nightly build on audi ( Red Hat 9 ) started at 2004-08-27 03:15:03 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 ---------------------------------------- == 179 tests, 9 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/execve2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-08-27 02:13:22
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-08-27 03:10:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow 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 ---------------------------------------- == 179 tests, 3 stderr failures, 0 stdout failures ================= helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |