Re: RFC: ``detach remote''

[Daniel Jacobowitz <drow@mvista.com>]

On Sun, Aug 11, 2002 at 11:15:07AM -0400, Andrew Cagney wrote:
> >On Fri, Aug 09, 2002 at 01:48:25PM -0400, Andrew Cagney wrote:
> >
> >>>Hold on a second.  Gdbserver is in wide use; that may not have been
> >>>true a couple of years ago, but the reason I've invested so much time
> >>>in maintaining it is a continually growing customer demand for it.
> >>>People use this, and they are already used to its behavior.
> >
> >>
> >>[Be careful to separate the interests of the fee paying customer from 
> >>the interests of GDB and the wider GDB community.  Fee paying customers 
> >>have an unfortunate habit of being very short sighted :-( :-)]
> >
> >
> >I get more non-customer feedback on gdbserver than customer feedback,
> >actually.  Poor choice of words.
> 
> I'm told HP once did a study to determine the debug requirements of a 
> typical user.  Turns out a typical debug session looks something like:
> 
> 	$ ./a.out
> 	segmentation fault, core dumped
> 	$ gdb ./a.out
> 	(gdb) run
> 	Program received sig seg
> 	10		a = *b;
> 	(gdb) print b
> 	$1 b = 0
> 	(gdb) quit
> 
> ``Advanced users'' get to use up/down and backtrace.
> 
> Depressing, eh?

Yeah.  It's certainly not universal, though...

> >>I'm a user, and I'd prefer to be able to type:
> >>
> >>	(gdb) target remote |ssh machine gdbagent
> >>	(gdb) file foo
> >>	(gdb) run
> >>	Program exited
> >>	<doh!>
> >>	(gdb) break main
> >>	(gdb) run
> >>	...
> >>	(gdb) detach
> >>	(gdb) monitor ps
> >>	(gdb) attach
> >>	.....
> >>
> >>instead of:
> >
> >
> >Some day :)  Those are nice ideas.
> 
> It's closer then you might thing.  All you need is:
> - attach packet
> - detach packet with a correct definition
> - auto-negotiate of extended-remote

And pipe support for target remote, and an agent which can communicate
over said pipe.  Neither terribly hard...

> >>I think the command sequence would be:
> >>
> >>	target remote
> >>	attach <remote-pid>
> >>	target child -- implicit remote/pid detach
> >>	attach <local-pid>
> >>
> >>(Red Herring -- ``target sim'' is equally confused.)
> >
> >
> >The difficulty is what to call "disconnect from the agent".  I don't
> >really like the ambiguity of the target stack here... I suppose adding
> >a "target none" will suffice, but right now the behavior when unpushing
> >a running target is to ask the user if they want to kill it.  That's
> >not going to work if we use this as the method to detach and leave the
> >agent running :)  Having "target none" detach and "target child" ask
> >you if you want to kill doesn't really work either.
> >
> >What do you think of letting the target control what happens when
> >another target is selected?  Remote targets could choose to detach. 
> >That's a little better.
> 
> More background:
> 
> Looking at the code and recalling comments (some verbal), the original 
> intent was that there could be several active targets.  This allows the 
> user to switch between targets:
> 
> 	target child
> 		a live process
> 	target core
> 		now look at the core file
> 	target child
> 		back to that live process
> 
> I don't know if it works.  I've never used it.
> 
> Turns out that this ideal was corrupted along the way because the 
> implementation only allowed one target of each type.  As a consequence, 
> ``target remote'' and ``target sim'' both zap ``target child''.

It doesn't work, anyway:
(gdb) target core core
A program is being debugged already.  Kill it? (y or n) 

I think that if you really want this to work, you need to have target
instances; so that saying "target core" creates a new instance of a
core target and you can control instances individually.  This is a long
way away and it isn't a goal I'm terribly interested in implementing.

> >Or, hey, here's a better idea.  A "disconnect" command.  Then "target"
> >can retain its current semantics (kill) and the user will have an
> >explicit way to disconnect if they want.
> 
> Hmmm!
> 
> Noteing the above -- there can be multiple active targets -- therefor 
> there does need to be a way of shutting down a specific target. 
> Presumably ``target none'' would shutdown all of them.

No, noting above, there might someday be multiple active targets. 
We're not there yet.

> Need to look at a table to see what operations are possible and then 
> figure out which map onto commands.

Tables and lists, I can do that!  Let's see what we've got.  I'll pick
a sampling of targets and operations.

Start with native debugging.  The basic things one wants are:
 - "run": create a new process.
 - "attach": Attach to a running process.
 - "detach": Detach from the current process.  Let it run.
 - "kill": End the current process.

I think we agree that the current meanings of these commands are right,
yes?

Then consider remote debugging of a simple ROM monitor.  All four of
the above commands are meaningless.  Currently, the only one of them
with meaning is "detach", which sends a D packet and disconnects.  The
ROM monitor can choose to remain stopped (most do, from what I've seen)
or resume when it sees the D packet.  It would be nice to have the
choice; I think that detach vs. disconnect is a reasonable way to
represent this.  Protocol side to be determined.  Perhaps disconnect
would send no packet at all, just close the connection?  I think that
would work.  But I digress.  Also, some ROM monitors might support
"restart", which currently gets lumped in with "run", but I believe
should be a special monitor command instead.  That might vary.

Then consider a simulator, linked in.
 - "run" means to restart the simulator
 - "kill" means to end the simulation
 - attach and detach have no apparent meaning
 - disconnect appears to have no useful meaning

Then consider a simulator, speaking a remote protocol, whichever remote
protocol it may be (I hypothesize that it should be extended-remote and
should reject some commands as inappropriate):
 - run/kill/attach/detach as above
 - disconnect now has meaning as with the ROM monitor

Now let's consider our friend the hypothetical all-singing all-dancing
remote process agent.  I think we've concluded that we want
"run"/"kill"/"attach"/"detach" to behave as with native debugging.  We
also need a couple of other commands:
 - Disconnect from the agent, leaving it in its current state, waiting
   for a new client
 - Terminate the agent

Terminating the agent can be a monitor command.  I like the idea of a
"disconnect" command.


One other thorny issue becomes what to do when the user quits or closes
the remote target etc.  Right now GDB offers the "kill" prompt as I
showed above.  For extended-remote that doesn't make a lot of sense to
me... I think that either "disconnect" or a "kill"/"terminate" sequence
makes more sense.  Thoughts?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer