Bugzilla – Full Text Bug Listing
| Summary: | Enhancement Proposal : Default directory for "post mortem" debug | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | stibbons <gaetan> | ||||||||
| Component: | cdt-debug-dsf-gdb | Assignee: | Marc Khouzam <marc.khouzam> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | Marc Khouzam <marc.khouzam> | ||||||||
| Severity: | enhancement | ||||||||||
| Priority: | P3 | CC: | cdtdoug, marc.khouzam, nobody, pawel.1.piech | ||||||||
| Version: | 7.0 | Flags: | marc.khouzam:
review?
(nobody) |
||||||||
| Target Milestone: | 8.1.0 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
stibbons
Created attachment 206005 [details]
Prototype solution
That is a nice user-friendly suggestion.
Attached is a prototype patch that does this, but only accepts absolute paths. I didn't have time to figure out how to figure out paths relative to the workspace.
(In reply to comment #0) > I would recommend to be able to specify in the "Core file" path a directory > path where core files are created (allowing entering workspace relative path), Another option came to mind. When the dialog is opened and the user selects a core file, we could remember the directory location that was used, and use it the next time the dialog is opened. The advantage of this solution is that remembering the directory would be done automatically, without the user having to open the launch configuration and consciously adding the path to the dialog box. I was thinking that we could store the path used in the dialog in the launch configuration itself. However, we could also, if possible, store that path in a project property. The idea here is that the location of core files will probably be the same for the same project. I got this idea looking at the core launch for CDI (CoreFilePrompter.java) Any opinions? BTW, I thought about doing a hybrid solution where: 1- the user could set a path in the dialog box 2- automatically store the path of the last prompt used The problem with such a solution is that step 2 would overwrite step 1, which may not be what the user wants. Therefore, we can either do #1 or #2. Or we could do both, but separately, which would mean that if a #1 is set, it takes precedence over #2. Personally, I think this is overkill for a minor enhancement. I think the user will be happy with #2, which is my preferred solution. I would recommend the first option, ie, setting the path in the settings, since the path is usually always the same (either the home, or a specific directory for different project).
Either first or second option, it could be very usefull if the path is saved somewhere in the project files (ie, I don't have to browse through the directories in search of my core files location each time eclipse is restarted). Ideally it could also support ${resource_loc:blablabla} and other variable to build path (like env variable page)...
(In reply to comment #4) > I would recommend the first option, ie, setting the path in the settings, since > the path is usually always the same (either the home, or a specific directory > for different project). Can you explain why you prefer option 1 (using the launch dialog) compared to option 2 (automatically saving the path when the user selects the first core file? > Either first or second option, it could be very usefull if the path is saved > somewhere in the project files (ie, I don't have to browse through the > directories in search of my core files location each time eclipse is > restarted). Yes, that will be the case. > Ideally it could also support ${resource_loc:blablabla} and other > variable to build path (like env variable page)... That only applies if we choose solution 1. I'll give it a try if we go that route. I think you have your answser ;)
I like the ${resource_loc:project/path/blabla} flexibility !
Created attachment 211154 [details]
Fix for DSF
The patch implements the proposed feature (option 1). It allows the user to set a directory path as a core file, which will be used as a root directory when triggering the prompt.
It supports absolute and relative paths for directories or core files. It also support the use of variables such as ${workspace_loc}
In the launch dialog I have replaced the explanatory string:
"Core file (leave blank to trigger prompt):"
with
"Core file (leave blank or select root directory to trigger prompt):"
There is one little problem with this solution that I didn't find a solution for. In the launch dialog, the user can press the "Browse" button to select the core file location, or now, also a directory path. The "Browse" button uses a FileDialog which only allows to choose a file and not a directory. The other option is to use a DirectoryDialog, but that only allows to choose a directory and not a file. I didn't find a way to allow the user to choose both a file or a directory.
This means that if the user wants to set a directory in the dialog, and wants to use "Browse" to do it, she will need to select a file name and then edit the path in the dialog to remove the file name, and only keep the directory.
The solution is only for DSF. I am not planning on doing it for CDI. If you would also like to see this done for CDI (the old GDB integration), please file a new bug. Created attachment 211155 [details]
JUnit tests for this feature
I created some unit tests to make sure we verify that we handle absolute and relative core file names, as well as parsing variables in the path.
The tests currently cannot test the new feature of setting only a directory because the prompt dialog would need to be triggered and the tests don't deal with the UI.
stibbons, are you able to test patches or do you need a build? I will be committing on Friday, but it would be nice to eventually know if this implementation fits with what you had in mind. Mikhail, when time permits, can you review the patch? I committed both patches to master. I can try to build it however I'm not very confortable with java dev (I'm using eclipse for C++). If you can send me a binary, I'll test it on monday (my plateform is linux 64b indigo). To what you describe, it seems to fit what I was thinking. I use both DSF and CDI (sometimes DSF make gdb crash), so I'll open a new bug if the need appears. Thank you very much for this patch, I really appreciate the way it was done ! You rocks ;) - Gaetan (In reply to comment #13) > I can try to build it however I'm not very confortable with java dev (I'm using > eclipse for C++). If you can send me a binary, I'll test it on monday (my > plateform is linux 64b indigo). I've started a new build on Hudson. I'll try to figure out how you can install that once it is ready. > To what you describe, it seems to fit what I was thinking. I use both DSF and > CDI (sometimes DSF make gdb crash), so I'll open a new bug if the need appears. "DSF makes gdb crash"? That is not good. I recommend you use GDB 7.4 or at least 7.3.1. If there are still crashes, it would be nice, when they happen, that you open a bug and attach the 'gdb traces'. That will help us a lot. http://wiki.eclipse.org/CDT/User/FAQ#I.27ve_been_asked_for_.27gdb_traces.27.2C_where_can_I_find_them.3F > > Thank you very much for this patch, I really appreciate the way it was done ! > You rocks ;) It is nice to have user feedback like this bug suggestion. Thanks. (In reply to comment #14) > (In reply to comment #13) > > I can try to build it however I'm not very confortable with java dev (I'm using > > eclipse for C++). If you can send me a binary, I'll test it on monday (my > > plateform is linux 64b indigo). > > I've started a new build on Hudson. I'll try to figure out how you can install > that once it is ready. Here is a link to a CDT repo that has the fix in it. I believe you can download it and install it to test the new feature: https://hudson.eclipse.org/hudson/job/cdt-nightly/968/artifact/releng/org.eclipse.cdt.repo/target/org.eclipse.cdt.repo.zip *** cdt git genie on behalf of Marc Khouzam ***
Bug 362039: New postmortem JUnit tests
[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=b00b1289721c67f40e4e2304fdd1c98d876d50ed
*** cdt git genie on behalf of Marc Khouzam ***
Bug 362039: New postmortem JUnit tests
[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=b00b1289721c67f40e4e2304fdd1c98d876d50ed
*** cdt git genie on behalf of Marc Khouzam ***
Bug 362039: New postmortem JUnit tests
[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=b00b1289721c67f40e4e2304fdd1c98d876d50ed
*** cdt git genie on behalf of Marc Khouzam ***
Bug 362039: Default directory for "post mortem" debug, as well as handling the use of variables in core/trace file specification.
[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=437d707cd93edf1398ef7f9d3dd77d76297fb336
*** cdt git genie on behalf of Marc Khouzam ***
Bug 362039: Default directory for "post mortem" debug, as well as handling the use of variables in core/trace file specification.
[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=437d707cd93edf1398ef7f9d3dd77d76297fb336
|