This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFC: ``detach remote''
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