| Re: [cdt-dev] Support for "target-detach" and "target-disconnect" |
|
I agree with Paul. If you look up disconnect and detach in the English
dictionary you'll find that they're very close in definition. The
distinction in meaning between the two in GDB is part of GDB's
history. For Eclipse's history Disconnect in the debugger has meant
the same thing as Detach has in GDB. So I don't think we can change
the meaning of Disconnect in Eclipse without confusing a lot of Eclipse
users. And the status quo is that GDB users new to Eclipse are
confused by the term "Disconnect" in the debugger. I don't think we
can change this fact without rewriting history. Pedro Alves wrote: To (try to) clarify things from GDB's perpective: - "disconnect" disconnects from the (remote) target. ... What of my suggestion to add the GDB disconnect action as "Disconnect Target". It's descriptive, unambiguous (unlike Detach vs. Disconnect) and it doesn't require changing Eclipse precedent. Cheers, Pawel Warren.Paul@xxxxxxxxx wrote: Having worked on various bare board and OS debuggers over the years, my view of connect vs. attach, and disconnect vs. detach, has mostly been between bareboard vs. process debugging. For example, I want to just connect to my board and "peek and poke", and when I'm done, I disconnect which simply closes the debug session. When there's an OS with processes/threads, I need to attach to one or more processes running in the OS, and when I'm done debugging that process, I can kill it, or detach from it. If I kill it, the process actually gets killed by the OS. If that was the last process being debugged then the debug session ends. If I detach from a process, we resume any suspended threads and then simply detach the debugger, leaving the process running. Anyway, not being a GDB guy I'm not sure if that's really the meaning of their two commands. The fact that the disconnect button has been used for detaching in the past, it may be confusing to users to suddenly change its meaning, even if the change is technically more correct. I guess if there's a real argument to have both disconnect and detach functionality, then this change may be necessary. But is there a real requirement to be able to detach the debugger but leave some threads suspended? FYI, in our products, both run-mode and stop-mode debugging, we simply use the platform's disconnect command to mean detach. If the launch is selected then we simply detach from all processes being debugged, and then close the session. If one or more processes are selected when the button is pressed, we disconnect from only those processes. Thanks, Warren-----Original Message----- From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of ext Marc Khouzam Sent: Thursday, April 15, 2010 11:47 AM To: CDT General developers list. Subject: RE: [cdt-dev] Support for "target-detach" and "target-disconnect"-----Original Message----- From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mikhail Khodjaiants Sent: April-15-10 12:06 PM To: cdt-dev@xxxxxxxxxxx Subject: Re: [cdt-dev] Support for "target-detach" and "target-disconnect" If you rename "Connect" to "Attach" we can add a button for "Detach" to the toolbar. :-(yes :-( That is not so good for the toolbar. My point was that having 'disconnect' on the toolbar, for GDB, doesn't not seem as useful as having 'detach'. Are we really forced to have GDB's 'disconnect' on the toolbar, just because the JDT/platform has named it 'disconnect'. Is that the only reason that we don't instead have GDB's disconnect in the view menu?_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev _______________________________________________cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev |