Community
Participate
Working Groups
1. Attaching to running application requires going through the debug configuration dialog. Easier approach would be adding an "Attach" item to Run menu that will show process selector and will ask for the rest of the information (i.e. project) if needed. 2. "Run to line" can only be used when debugger is running. It would be more effective if "Ctrl+r" shortcut would always work and would start the debugger if needed.
(In reply to comment #0) > 1. Attaching to running application requires going through the debug > configuration dialog. > Easier approach would be adding an "Attach" item to Run menu that will show > process selector and will ask for the rest of the information (i.e. project) if > needed. This would be easy. We could add an entry to the existing "Debug As..." menu. Could you change the title of this bug to focus on that first enhancement? > 2. "Run to line" can only be used when debugger is running. It would be more > effective if "Ctrl+r" shortcut would always work and would start the debugger > if needed. Interesting. We would find the project from the editor, and then do a "Debug As->Local C/C++ application" and then a automatic run-to-line operation. Does not sound trivial, but does sound cool. Can you open a separate bug for that second enhancement?
(In reply to comment #1) > (In reply to comment #0) > > 1. Attaching to running application requires going through the debug > > configuration dialog. > > Easier approach would be adding an "Attach" item to Run menu that will show > > process selector and will ask for the rest of the information (i.e. project) if > > needed. > > This would be easy. > We could add an entry to the existing "Debug As..." menu. "Debug As..." is meant to be context-sensitive (i.e. it uses current editor selection). I.e. the user may want to attach to random application that hung and the IDE will try to use current project. Does attaching require project for any reason other then source resolution? > Could you change the title of this bug to focus on that first enhancement? Done.
(In reply to comment #2) > (In reply to comment #1) > > (In reply to comment #0) > > > 1. Attaching to running application requires going through the debug > > > configuration dialog. > > > Easier approach would be adding an "Attach" item to Run menu that will show > > > process selector and will ask for the rest of the information (i.e. project) if > > > needed. > > > > This would be easy. > > We could add an entry to the existing "Debug As..." menu. > > "Debug As..." is meant to be context-sensitive (i.e. it uses current editor > selection). I.e. the user may want to attach to random application that hung > and the IDE will try to use current project. I tried no selecting any project and then doing "Debug As..." from the Run menu, and I think we could add an entry there for this case. But I do agree that it makes it look like you need to select a project. > Does attaching require project for any reason other then source resolution? Attaching does not require a project, you can leave that field empty. What I do for a local attach, is create a generic launch that I use all the time. This may a way to improve this use-case. CDT could even provide a pre-filled launch that would allow to debug any binary using attach, if we want to make it really easy for the user.
I get one steady stream of negative feedback from users/customers about launching in Eclipse. The whole experience blows. We definitely need to make it more natural.
My proposed UI - https://git.eclipse.org/r/#/c/5975/ "Attach..." action will appear in the Run menu below Run/Debug/Profile group. It is a command so user may also assign a shortcut and/or use Ctrl+3 for quick access.
(In reply to comment #5) > My proposed UI - https://git.eclipse.org/r/#/c/5975/ > > "Attach..." action will appear in the Run menu below Run/Debug/Profile > group. It is a command so user may also assign a shortcut and/or use Ctrl+3 > for quick access. Thanks Eugene. This approach is something we should definitely look further into. Recently, we discussed a similar but maybe slightly more generic solution, which would allow a user to avoid the launch dialog to: 1- local debug (attach or new process) 2- remote debug (attach or new process) You can see a couple of emails starting here: http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg24900.html One difference between what we discussed and your patch is if we should create a launch configuration when the user uses the proposed new command. You create a temporary launch that is not kept, while we thought of creating a real launch. There are a couple of advantages is keeping the launch: 1- the user can modify the launch if needed without having to create it from scratch 2- the new quick-commands we would add could automatically re-use that modified launch, which is a nice way to easily 'modify' those commands But this is mostly a discussion at this time, although I have a quick hacked prototype as a proof-of-concept. Another difference is how to trigger this shortcut launch. You used a new command in the Run menu. This may be a good solution, I'm not sure yet. We proposed using the existing launch shortcuts infrastructure of the platform. We should also clarify what we feel would be best for the user in this case. Let's continue this discussion to try to improve the user-experience with our launch system. I'll clean-up my prototype and post it for opinions soon.
Marc, right now I am looking into remote debug and I am thinking about a debug wizard that would provide a consistent way for the user to start debugging in one of several modes (local, local attach, connect to running gdbserver, start gdbserver on remote host and connect to it). I hope I will have something by early October and I can discuss with my management contributing this upstream if there's aligned with what CDT needs.
(In reply to comment #7) > Marc, > right now I am looking into remote debug and I am thinking about a debug > wizard that would provide a consistent way for the user to start debugging > in one of several modes (local, local attach, connect to running gdbserver, > start gdbserver on remote host and connect to it). I hope I will have > something by early October and I can discuss with my management contributing > this upstream if there's aligned with what CDT needs. That sounds interesting. Please aware of a coming change from Bug 344890 which will allow to start debugging a new process on a remote target. With this change, CDT will be able to: 1- attach a process using the 'Connect' command 2- start a new process using the new 'Debug new process' command and this will work for remote or local sessions, any time during the debug session. To me, this means that the line between local and local-attach becomes blurry, as well as the line between remote and remote-attach. I was hoping to see a local launch shortcut and a remote launch shortcut, where the user could then use the two above commands to do whatever they need.
*** Bug 426022 has been marked as a duplicate of this bug. ***
