|
From: Tom H. <to...@co...> - 2005-10-04 08:27:57
|
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.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|