This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: ``detach remote''


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

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

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.

> >My usual pessimisim aside, I think I like your idea.  We need to think
> >about the change a little more, because right now "detach" offers a way
> >to disconnect from the agent _without killing it_, for the normal
> >remote agent.  "target" would offer to kill it.  Got a suggestion for
> >what to call this new command?
> 
> [realism :-)]
> 
> I think you're saying that detach, for current gdbserver, drops the tcp 
> connection but the server and the debugged program both hang around. 
> That is a gdbserver decision and not, I think, GDB's problem.  If the 
> GDB server decides to hang around, what does GDB care?
> 
> Mind you adding documented gdbserver options (and perhaphs a monitor 
> command) to control this behavour wouldn't go astray.

Need to decide what it should be first.

> >I'd like detach to behave the "roughly" same way between remote and
> >extended-remote, especially if we're talking about autodetecing
> >extended-remote; that is, I'd like "detach" to say "not supported" when
> >using target remote, instead of maintaining its current behavior.  Make
> >sense?  And perhaps include a reference to the new way of detaching
> >from a target, whatever it may be.
> 
> or, print the warning message indicating that ``target none'' should be 
> used to disconnect from the target.

Sure...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]