Re: Leaving visible breakpoints in memory/core (Was: Breakpoint stepping)

[Phil Muldoon <pmuldoon at redhat dot com>]

Mark Wielaard wrote:
> Hi Phil,
>   
> 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!)
>   

Well I think in the kernel dumping core there is nothing to be done with 
2) other than just let it happen. I just wonder if the entry-point of 
the program being rewritten by Frysk in this scenario will cause 
confusion. In the case of fcore, we can always strip all this stuff 
beforehand, dump the core, and then put it all back. But in the case of 
gcore and google's coredumper that won't be the case. A process has no 
idea when a userland program like gcore/fcore is creating a coredump of it.

However until there is a better place to store this stuff other than at 
the entry-point address, then I guess the question it sort of moot.

Regards

Phil
> 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
>