Hi Phil,
On Thu, 2007-07-05 at 14:39 +0200, Mark Wielaard wrote:
Though I
suspect if you are dumping core while stepping a process one is in
deeper trouble than one suspects ;)
I admit to not have thought of this scenario. That is indeed troublesome
since some breakpoints might actually still be embedded in the Proc code
memory while the kernel writes out the core file. Have to think about
that. What scenarios are there for a process to dump core? And is there
any way for us to intercept and quickly remove any changes we done to
the code segments before that?
After thinking about it a bit more and some off-list chatter I think
there are 2 scenarios here. 1) Having our inserted breakpoints show up
in memory views as used in frysk. 2) Inserted breakpoints show up in
core dumps of programs we are analyzing. It is probably not worth it to
worry about 2) since as you say the user has deeper troubles then. And
if they want to analyse the actual core file later on it is probably
even more fair to make sure the breakpoints are still in the core file
so they have a real picture of what went wrong (it could even have been
frysk's fault!)
But 1) is a problem since it would distort the view of the user while
using frysk. So there is now bug #4761 and it is on my TODO list to
create a memory view that the "non-breakpoint aware" parts of Frysk will
use for memory inspection. The use case is to have the fhpd or frysk-gui
insert a breakpoint, stop at it, and let the user inspect the code
instructions around the breakpoint. This should not show traces of the
breakpoint even though frysk might still have it inserted.
Cheers,
Mark