Community
Participate
Working Groups
Build id: 20130919-0819 Fork from Bug 332993, comment 27. "Type" field from CDT Breakpoint property dialog should allow a drop-down choice between "Regular","Hardware", "Temporary" and "Hardware Temporary" breakpoint type. A breakpoint type could be edited: - either from "Add Breakpoint" dialog before being set on target - or from regular breakpoint property dialog.
Posted draft version to https://git.eclipse.org/r/#/c/21809/ Works on master sources without changes from Bug 332993. Limitation would be that there's no hint on breakpoint type (i.e. no type specific icon).
Updated gerrit with: - HW breakpoint icons per breakpoint type - Limit breakpoint type field editor to address, line and function breakpoints IMHO, current patch works as expected for DSF-GDB. Works as well for GDB-CDI debug model with one limitation: once installed in GDB, breakpoint type cannot be changed from UI though breakpoint property dialog though it does allow this. You can end up with breakpoints displayed as HW breakpoints but in GDB the breakpoints would actually be regular.
Created attachment 239960 [details] HW breakpoint icon Proposed HW breakpoint icon
I've tried the patch and it works fine. I have comments re the code though. Is this just a prototype or you pretty much done with it?
(In reply to Mikhail Khodjaiants from comment #4) > Is this just a prototype or you pretty much done with it? I am pretty much done. I've updated patch also for CDI backend to properly handle a breakpoint type change. Please review the code.
Pushed to master.
Teodor, I think we need to add this feature to N&N. Can you do that, please? Just a screenshot and a short note.
Done. Added to N&N for 8.4 https://wiki.eclipse.org/CDT/User/NewIn84#Change_breakpoint_type
Thanks!
This look great! Thanks for doing this. Now that we can set temporary and hardware breakpoints, we need to discuss a couple of things, I have opened bugs about each item if there wasn't one already: 1- there is no way to re-install a tmp bp. If I set a tmp bp in a loop, after the first hit, it will become uninstalled but still show in eclipse. If I want to install it another time, currently, the only way is to create a new one. It was previously mentioned somewhere that we could have an action on breakpoints to "re-install". This could be helpful in this case or in the case where an installation fails but the user wants to try again. See Bug 428925 2- GDB cannot set hw breakpoints before the program is started. This means any hw bp set in eclipse will fail to install when launching a second time. See bug 395404. Because of problem #1, the user can only delete the existing bp and re-create it. 3- Setting a regular breakpoint and then changing it to hardware from CDT causes a segfault when the breakpoint is hit. See Bug 428929.
(In reply to Marc Khouzam from comment #10) > This look great! Thanks for doing this. > > Now that we can set temporary and hardware breakpoints, we need to discuss a > couple of things, I have opened bugs about each item if there wasn't one > already: > > 1- there is no way to re-install a tmp bp. If I set a tmp bp in a loop, > after the first hit, it will become uninstalled but still show in eclipse. > If I want to install it another time, currently, the only way is to create a > new one. It was previously mentioned somewhere that we could have an action > on breakpoints to "re-install". This could be helpful in this case or in > the case where an installation fails but the user wants to try again. See > Bug 428925 > I agree, we need this feature. > 2- GDB cannot set hw breakpoints before the program is started. This means > any hw bp set in eclipse will fail to install when launching a second time. > See bug 395404. Because of problem #1, the user can only delete the > existing bp and re-create it. > You can also disable/enable the hw breakpoint after the program is started with the same effect. Another problem in this particular case is the error message that appears with the warning sign. It is too generic because breakpoint-related error messages are not propagated up to the top level. This one is easy to fix. > 3- Setting a regular breakpoint and then changing it to hardware from CDT > causes a segfault when the breakpoint is hit. See Bug 428929. This is a gdb issue, right?
(In reply to Mikhail Khodjaiants from comment #11) > > 2- GDB cannot set hw breakpoints before the program is started. This means > > any hw bp set in eclipse will fail to install when launching a second time. > > See bug 395404. Because of problem #1, the user can only delete the > > existing bp and re-create it. > > > > You can also disable/enable the hw breakpoint after the program is started > with the same effect. Cool, I was not aware of that. > Another problem in this particular case is the error > message that appears with the warning sign. It is too generic because > breakpoint-related error messages are not propagated up to the top level. > This one is easy to fix. Yes, we need to better report errors. > > 3- Setting a regular breakpoint and then changing it to hardware from CDT > > causes a segfault when the breakpoint is hit. See Bug 428929. > > This is a gdb issue, right? We need to investigate a little and hopefully report it to GDB, but I'm pretty sure we'll close as NOT_ECLIPSE on our side. I still wanted to document it, so we don't forget to follow-up.
(In reply to Marc Khouzam from comment #12) > (In reply to Mikhail Khodjaiants from comment #11) > > > > Another problem in this particular case is the error > > message that appears with the warning sign. It is too generic because > > breakpoint-related error messages are not propagated up to the top level. > > This one is easy to fix. > > Yes, we need to better report errors. > I have created Bug 428990 for a patch. I will push a patch for review there.
*** Bug 391490 has been marked as a duplicate of this bug. ***
