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

[Mark Wielaard <mark@klomp.org>]

[-- Attachment #1: Type: text/plain, Size: 2815 bytes --]

Hi Phil,

On Tue, 2007-07-17 at 10:46 -0500, Phil Muldoon wrote:
> Mark Wielaard wrote:
> What's the argument about just dumping the task's memory as is, with all 
> breakpoints there? A corefile is a representation of that process and 
> it's thread as it is at that time ...

Because you don't know why/what those breakpoint instructions are doing
there. Since none of the observer logic is saved together with the core
file you wouldn't know why and what that breakpoint instruction is doing
there. Worse, you don't even know what is underneath it.

> And besides, this is only addressing a tiny corner case of someone 
> running fcore on a process that is being debugged with Frysk at that 
> time. I can't think of a scenario why I would do that. Can you?

Yes. The scenario using fcore I have in mind is one where a user has
reported some behavior that cannot easily be explained and that only
happens in some production environment. You might have an idea why it
might happen but need proof and would need to inspect the actual state
of the process more closely when it happens. But the user doesn't want
to hand over the whole running process to you so you can stop it
completely. So you write a little frysk-core based program that triggers
under certain conditions (possibly involving breakpoints) and that
generates a core file of the full process state but that you then want
to inspect offline (maybe even by a third person with something like
gdb). You want the fcore generated file to represent the state of the
process as if it was pristine, not with lingering low level breakpoint
or other frysk artifacts in it so you know what the actual code was
doing.

>  If they 
> were debugging with GDB and fcore was run on that process, the included 
> core image would have all the break point information.

Yes, although in practise this currently doesn't work since our ptrace
based implementation won't let two different processes attach to the
same process.

> It seems like a lot of work for a very small edge case?

But it isn't just for fcore. And as you showed above maybe fcore should
have an option to select whether or not to dump logical memory or raw
memory. It is mainly used for other observers inspecting the task. We
don't want to retract all low level breakpoints when one task stops (so
other tasks can keep running and possible hit that or another low level
breakpoint). But when looking at the actual memory dump we want it to
show what would actually be there. The user is most likely interested in
the actual instruction at that point, not in the frysk inserted
breakpoint instruction. This makes the higher level tasks not need to
worry how the actual implementation of some lower level task actually
works.

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]