Re: gdbMI/790: -target-attach not implemented

[Andrew Cagney <ac131313 at redhat dot com>]

The following reply was made to PR gdbMI/790; it has been noted by GNATS.

From: Andrew Cagney <ac131313@redhat.com>
To: alain@qnx.com, gdb-gnats@sources.redhat.com,
	"J. Johnston" <jjohnstn@redhat.com>
Cc:  
Subject: Re: gdbMI/790: -target-attach not implemented
Date: Tue, 26 Nov 2002 16:38:10 -0500

 http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=790
 
 Jeff J writes:
 
 > Could you further explain your comments found in gdb/790 on how it should be fixed.  I am not clear with what you want and why you want it.  What is
 > the benefit of having a vector of operations if they will end up calling the same function?  Could you also explain in the context of attach instead
 > of target remote.
 > 
 > The one major difference I see between MI and CLI is that CLI will want to query
 > the user if they want to kill the current target and MI should just go ahead.
 > I could break out the check so that both could share common code but I 
 > don't see why the added complexity of a function vector is required.
 
 Hmm, yes, I see your point.  While the target->attach() method has 
 problems, the implementation of this specific command doesn't need those 
 problems fixed.
 
 Re-vamping attach_command() into several gdb_...() methods (and moving 
 "attach" to cli/cli-attach.c I guess) would do the trick.
 
 --
 
 What problem?
 
 The target vector should make available methods that allow sequences like:
 	target->open()
 	target->attach()
 or
 	target->open()
 	target->create_inferior()
 For a remote target, though ``(gdb) target remote ...'' is a direct call 
 to remote->open(), and yet it is expected to implement semantics that 
 better match target->attach() (i.e., connect to a running target).  This 
 confusion needs to be resolved.
 
 Andrew