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

[Andrew Cagney <cagney@redhat.com>]

Mark,

Expanding on our discussion:

-> user examining memory: breakpoints invisible
-> process dumps core via kernel: breakpoints are visible (no choice 
with current kernel infrastructure)
-> user requests fcore: breakpoints should not be visible

I.e., breakpoints and their implementation are not visible to the user 
(or beyond frysk.proc)

However, for our own debugging sanity, we will also need a way to 
examine the raw/modified memory to see what the program is really 
executing :-)

Andrew

Mark Wielaard wrote:
> 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
>