|
From: Bob R. <bo...@br...> - 2005-10-04 12:01:24
|
On Tue, Oct 04, 2005 at 09:27:46AM +0100, Tom Hughes wrote: > In message <4341F283.6030600@BitWagon.com> > John Reiser <jreiser@BitWagon.com> wrote: > > > Tom Hughes wrote: > >> In message <4341B3F4.9060605@BitWagon.com> > >> John Reiser <jreiser@BitWagon.com> wrote: > >> > >> > >>>>2) I'm not sure how you're supposed to continue execution from gdb. > >>> > >>>"detach" then "quit": > >> > >> > >> A simple quit has always been enough in my experience - that was > >> certainly the intention. > >> > >> Even though I wrote the current debugger attachment code it isn't > >> actually something I actually use very often - hardly ever in > >> fact - so there might well be a problem. > > > > Looking carefully at the process numbers, the debugger is not dealing > > with the original process itself, but with a fork(). [In the output below, > > the original process is 9614, the fork is 9615, and the gdb is 9616.] > > So the debugger cannot alter the state of the original process, such as > > by "set var my_var = 123" Why? Running gdb on yourself works, and > > with proper care can even be told to use the user's symbols, and ignore > > valgrind's. See the second example below. [It might be necessary to > > spoon-feed some 'add-symbol-file' commands ahead of interactive input.] > > The reason we fork a copy of the process is that we want the debugger > to see the simulated register set rather than the real register set. > > So we fork a copy then use ptrace to change that copy's registers to > hold the simulated registers and then attach a debugger to the copy > and wait for the debugger to finish. When the debugger is done we > make sure the copy is dead and then carry on. This works most of the time, of course. However, if your program changes the state of something external (filesystem, network sockets, ...), then when you "carry on", something could potentially hit the fan. In this situation, the best bet is to fix the problem and restart. Bob Rossi |