Community
Participate
Working Groups
When "break-insert" fails the error message should be passed to the status of the parent request monitor. See handleError() in GDBBreakpoints_7_0::addBreakpoint(). The next layer (MIBreakpointsManager::installBreakpoint) also ignores the status information coming from the previous layer. Same applies to tracepoint error handling.
Created attachment 189324 [details] Fix.
Created attachment 189327 [details] Same patch with Messages.properties Forgot to update Message.properties
You don't want to make the change directly in MIBreakpoints, so it is available for older GDBs? What kind of error can happen? I was trying to see the change in actions, but I don't know how to trigger an error :-)
Created attachment 189432 [details] Modified patch to include MIBreakpoints changes.
(In reply to comment #3) > You don't want to make the change directly in MIBreakpoints, so it is available > for older GDBs? > Sorry, I still get confused with the MI and GDB separation. I would expect GDBBreakpoints and GDBBreakpoints_7_0. > What kind of error can happen? I was trying to see the change in actions, but > I don't know how to trigger an error :-) Replace the "REGULAR" breakpoint type by "HARDWARE" and you should get an error, that's how I get it.
Created attachment 189449 [details] Screenshot of an error marker (In reply to comment #5) > (In reply to comment #3) > > You don't want to make the change directly in MIBreakpoints, so it is available > > for older GDBs? > > > > Sorry, I still get confused with the MI and GDB separation. I would expect > GDBBreakpoints and GDBBreakpoints_7_0. Me too :-) Originally, all the MI classes were meant to be used by people that use the MI protocol but not GDB. I don't think this is being done at all. I would like to remove all the MI packages and have only GDB packages, but I was hesitant to make such a big change. > > What kind of error can happen? I was trying to see the change in actions, but > > I don't know how to trigger an error :-) > > Replace the "REGULAR" breakpoint type by "HARDWARE" and you should get an > error, that's how I get it. What I did instead was to go to MIBreakInsert and force "allowPending=false;", then I set a breakpoint in a file that is not part of any of my debug sessions. Attached is the resulting marker screenshot. In this particular case, are things more confusing than before? The marker says there is no sourcefile named "blah" while I'm actually looking at the source code of "blah". I could even have a valid bp installed at that location for another debug session, but as long as there is once session that is not including this file, I get the confusing error. The whole bp handling is really poor, as we mentioned in the multicore conf calls, so I'm not sure if there is any better way to handle the case you are tackling. What error message do you see for your scenario?
(In reply to comment #6) > The whole bp handling is really poor, as we mentioned in the multicore conf > calls, so I'm not sure if there is any better way to handle the case you are > tackling. > Without my patch you would get a warning marker with something like "Breakpoint failure" which is also confusing. When a breakpoint installation fails a warning marker is added to the breakpoint's resource which is confusing too. I am currently evaluating the feasibility of https://bugs.eclipse.org/bugs/show_bug.cgi?id=238954 for DSF/GDB. I think it is doable, but could be even more confusing in some cases. > What error message do you see for your scenario? "No hardware breakpoint support in the target", which is quite meaningful in my case.
(In reply to comment #7) > (In reply to comment #6) > > The whole bp handling is really poor, as we mentioned in the multicore conf > > calls, so I'm not sure if there is any better way to handle the case you are > > tackling. > > > > Without my patch you would get a warning marker with something like "Breakpoint > failure" which is also confusing. When a breakpoint installation fails a > warning marker is added to the breakpoint's resource which is confusing too. > I am currently evaluating the feasibility of > https://bugs.eclipse.org/bugs/show_bug.cgi?id=238954 for DSF/GDB. I think it is > doable, but could be even more confusing in some cases. Having context-aware breakpoints would be great. We have some requirements about that too. Anyway, about this patch, what do you think of adding a prefix to the error message? Something like "Bp failure: <error message>". Is that too much? I leave it up to you. +1 on the patch.
(In reply to comment #8) > Anyway, about this patch, what do you think of adding a prefix to the error > message? Something like "Bp failure: <error message>". Is that too much? > > I leave it up to you. > +1 on the patch. I'll update the patch later. At least we should pass the exception to the higher level.
*** This bug has been marked as a duplicate of bug 428990 ***
