Community
Participate
Working Groups
This is an API-breaking change, necessary because the breakpoint "number" provided by gdb has evolved so that it numbers breakpoints independently for each process being debugged. For example, bkp1 for process1 would be number "1.1". Bkp2 would be "1.2". Process2 would have its own bkp1: "2.1".
New Gerrit change created: https://git.eclipse.org/r/68524
(In reply to Marc Dumais from comment #0) > This is an API-breaking change, necessary because the breakpoint "number" > provided by gdb has evolved so that it numbers breakpoints independently for > each process being debugged. > > For example, bkp1 for process1 would be number "1.1". Bkp2 would be "1.2". > Process2 would have its own bkp1: "2.1". Do you know where the process number comes from? Is it the inferior's id?
(In reply to Mikhail Khodjaiants from comment #2) > Do you know where the process number comes from? Is it the inferior's id? yes, I believe it is the inferior id, as internally known to gdb.
(gdb) info inferior Num Description Executable 3 <null> /home/lmckhou/testing/loopsecond 2 <null> /home/lmckhou/testing/loopfirst * 1 process 24685 /home/lmckhou/testing/loopfirst (gdb) info break Num Type Disp Enb Address What 1 breakpoint keep y <MULTIPLE> 1.1 y 0x000000000040055c in main() at loopfirst.cc:9 inf 2 1.2 y 0x000000000040055c in main() at loopfirst.cc:9 inf 1 3 breakpoint keep y <MULTIPLE> 3.1 y 0x000000000040054c in main() at loopfirst.cc:7 inf 1 3.2 y 0x000000000040054c in main() at loopfirst.cc:7 inf 2 3.3 y 0x000000000040054c in main() at loopsecond.cc:8 inf 3
Mikhail, I wanted to discuss the comment you added on the review (same comment in two places): "I think we should also add methods that return the process number and the breakpoint number in the process. It will encapsulate the parsing of the breakpoint's identifier string. Otherwise the clients of this class that parse the identifier would be affected by any change in the identifier format." The goal for this week was to quickly do the API-breaking changes, before API freeze. What you suggest makes sense, but can be added as new APIs later. Is that ok with you?
(In reply to Marc Dumais from comment #5) > Mikhail, > > I wanted to discuss the comment you added on the review (same comment in two > places): > > "I think we should also add methods that return the process number and the > breakpoint number in the process. It will encapsulate the parsing of the > breakpoint's identifier string. Otherwise the clients of this class that > parse the identifier would be affected by any change in the identifier > format." > > The goal for this week was to quickly do the API-breaking changes, before > API freeze. What you suggest makes sense, but can be added as new APIs > later. Is that ok with you? Sure, I thought about it too. The only problem is that we can add new methods only in 9.1, right?
(In reply to Mikhail Khodjaiants from comment #6) > Sure, I thought about it too. The only problem is that we can add new > methods only in 9.1, right? yes, that's correct. More work will also be required to actually parse and use the new breakpoint number format, but at least we will be able to proceed for 9.1 instead of waiting for CDT 10.
(In reply to Marc Dumais from comment #7) > (In reply to Mikhail Khodjaiants from comment #6) > > Sure, I thought about it too. The only problem is that we can add new > > methods only in 9.1, right? > > yes, that's correct. More work will also be required to actually parse and > use the new breakpoint number format, but at least we will be able to > proceed for 9.1 instead of waiting for CDT 10. Not sure I understand the difficulties. Assuming that breakpoint's number format is 'x.y' I suggested adding two new methods to MIBreakpoint class, something like the following: int getInferiorNumber(), which would return the first part of a complex breakpoint number, or 0 when the breakpoint number is a single integer. int getBreakpointNumber(), which would return the breakpoint's number in the inferior, i.e. the second part of the complex breakpoint number. The implementation of both methods seem to be very easy unless I missing something here. Since MIBreakpointDMData is a wrapper around MIBreakpoint the same methods should be added to it too.
(In reply to Mikhail Khodjaiants from comment #8) > Not sure I understand the difficulties. Assuming that breakpoint's number > format is 'x.y' I suggested adding two new methods to MIBreakpoint class, > something like the following: > > int getInferiorNumber(), which would return the first part of a complex > breakpoint number, or 0 when the breakpoint number is a single integer. > > int getBreakpointNumber(), which would return the breakpoint's number in the > inferior, i.e. the second part of the complex breakpoint number. > > The implementation of both methods seem to be very easy unless I missing > something here. > > Since MIBreakpointDMData is a wrapper around MIBreakpoint the same methods > should be added to it too. At this point, we have not thought about the way forward enough to commit to adding these APIs. They do seem to make sense, but we want to think about it some more. BTW, I had a talk with Marc K., and we are permitted to add APIs until M7, so for about another month.
New Gerrit change created: https://git.eclipse.org/r/68796
Gerrit change https://git.eclipse.org/r/68524 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=c0109d378d90e0b1fdfe6c1d7fa52bc5bdd46ac5
New Gerrit change created: https://git.eclipse.org/r/68841
Gerrit change https://git.eclipse.org/r/68841 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=11c94f2755612d96c3fd8c50d8b5b75cb77f78b1
