|
From: James N. <jne...@ec...> - 2005-09-08 18:56:59
|
How difficult would it be to get Valgrind to be able to attach to a process that is already running? It seems to me that the only stumbling block would be that you have to load valgrind into the middle of the process's address space, since you don't get to set up the address space ahead of time. To clarify, my motivation is that when I detect an abnormal event in a running program (through other means), I would like to be able to have valgrind take over (with a tool that I'm developing), but I don't want to pay the performance cost of running valgrind 100% of the time. So, for example, it would be acceptable to start the program in a special way (perhaps reserving a piece of address space for valgrind to later be loaded into), as long as I can run the program natively initially, and be able to switch to Valgrind in mid-execution. I'm interested both in whether this is fundamentally possible, and an idea of what things would need to be done to actually implement it. Thanks! -Jim |
|
From: Robert W. <rj...@du...> - 2005-09-11 18:22:45
|
> I'm interested both in whether this is fundamentally possible, and an=20 > idea of what things would need to be done to actually implement it. I don't think this is possible. Valgrind creates a lot of state that wouldn't be around if it started half-way through the program (e.g. memory validity information.) Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Oswald B. <os...@kd...> - 2005-09-11 21:29:39
|
On Sun, Sep 11, 2005 at 10:58:29AM -0700, Robert Walsh wrote: > > I'm interested both in whether this is fundamentally possible, and an > > idea of what things would need to be done to actually implement it. > > I don't think this is possible. Valgrind creates a lot of state that > wouldn't be around if it started half-way through the program > (e.g. memory validity information.) > valgrind != memcheck. "attachabliity" might well be achievable for tools that don't preclude it inherently. probably it depends on how flexible the new memory manager will be in that regard. but then, i have no idea what i'm talking about ... :) -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. |
|
From: Nicholas N. <nj...@cs...> - 2005-09-11 23:02:21
|
On Sun, 11 Sep 2005, Oswald Buddenhagen wrote: > On Sun, Sep 11, 2005 at 10:58:29AM -0700, Robert Walsh wrote: >>> I'm interested both in whether this is fundamentally possible, and an >>> idea of what things would need to be done to actually implement it. >> >> I don't think this is possible. Valgrind creates a lot of state that >> wouldn't be around if it started half-way through the program > >> (e.g. memory validity information.) > > valgrind != memcheck. That's true, but it doesn't affect Robert's point, as there is lots of other state, and Valgrind very carefully controls many things so they are done in just the right way. > "attachabliity" might well be achievable for tools > that don't preclude it inherently. probably it depends on how flexible > the new memory manager will be in that regard. Not flexible enough, I predict. Attachability is not a design goal, it would require too many deep changes. Nick |
|
From: Josef W. <Jos...@gm...> - 2005-09-12 00:44:41
|
On Thursday 08 September 2005 20:56, James Newsome wrote: > How difficult would it be to get Valgrind to be able to attach to a > process that is already running? It seems to me that the only stumbling > ... As others have said, it is not a design goal of VG to be able to attach to a running process, and would need quite much changes if possible at all. Intel's PIN tool, quite similar to VG, says to able to do this (but not for multithreaded code?). Aside from that, with VG, you could start your tool in non-instrument mode, and switch to full instrumentation later, by invalidating VG's translation cache. Thus your program first would run at speed of "valgrind --tool=none". Josef |
|
From: James N. <jne...@ec...> - 2005-09-12 20:55:36
|
So it sounds like it *may* be possible in general, but would be non-trivial to modify Valgrind to do so. I was thinking of trying the code-cache invalidation trick, glad to hear a second opinion that it should work :). Perhaps I'll take a closer look at PIN as well. Thanks all for your feedback! -Jim On Sep 11, 2005, at 1:58 PM, Robert Walsh wrote: >> I'm interested both in whether this is fundamentally possible, and an >> idea of what things would need to be done to actually implement it. > > I don't think this is possible. Valgrind creates a lot of state that > wouldn't be around if it started half-way through the program (e.g. > memory validity information.) > > Regards, > Robert. > > -- > Robert Walsh > Amalgamated Durables, Inc. - "We don't make the things you buy." > Email: rj...@du... |
|
From: Nicholas N. <nj...@cs...> - 2005-09-12 20:59:16
|
On Mon, 12 Sep 2005, James Newsome wrote: > So it sounds like it *may* be possible in general, but would be non-trivial > to modify Valgrind to do so. Very non-trivial :) > I was thinking of trying the code-cache invalidation trick, glad to hear a > second opinion that it should work :) It's a *much* simpler approach, definitely worth trying first. Nick |