Community
Participate
Working Groups
This bug is meant to track the development of the overall Tracepoint support as part of DSF-GDB. This work is based on the new Tracepoint support that is coming to GDB. Preliminary information of GDB's new support can be found here: http://sourceware.org/ml/gdb/2009-01/msg00175.html http://sourceware.org/ml/gdb/2009-01/msg00176.html The work for DSF-GDB will need to keep up with the actual result of GDB's new implementation of tracepoints. I will make an attempt to also support tracepoints that are provided with previous versions of GDB; however, the main focus is to support the new tracepoint GDB feature. Old tracepoint support are described in the GDB manual here: http://sourceware.org/gdb/download/onlinedocs/gdb_11.html#SEC84 Below is a summary of the design/requirement to DSF-GDB that are being proposed. Comments and questions are very welcomed. Implementation details will be part of patches or comments to this bug. I will also use the mailing list when more complicated decisions must be made. Things to know: -------------- In GDB, Tracepoints will be supported using the gdbserver agent but not natively (yet?). Note that native use of tracepoints can still be achieved by using gdbserver directly on the host. The 'new' Tracepoints are very much like breakpoints, except that they do not keep the program stopped. In fact, "slow" tracepoints (see below) are implemented using breakpoints. Like a breakpoint, a tracepoint has the following attributes: 1- associated with a code line or address 2- has a dynamically user-defined condition determining if tracepoint should trigger 3- has a dynamically user-defined set of actions determining what the tracepoint should do 4- can be enabled/disabled Specific to tracepoints are the following attributes: A- A user-specified passcount which when reached, will stop all tracing. B- Actions are one of the following: 'eval', 'collect' and 'while-stepping' C- Tracepoints are not installed on the target at creation; instead, they are installed when a tracing experiment is started. D- if a remote debugging session is terminated, leaving the target running, tracepoints are _not_ removed from the target, and an ongoing tracing experiment continues. Reconnection to the target is possible. E- Conditions and Actions can make use of the proposed new Trace State Variables (see below definition). Slow tracepoints are tracepoints based on actual breakpoints that automatically resume the program as soon as the tracepoint actions have been performed. Such tracepoints are not considered very efficient and are referred to as "slow". Fast tracepoints are tracepoints that patch the binary to insert jump instructions. Those jumps lead the execution to collect the data and then back to the normal program. These tracepoints are highly efficient and are referred to as "fast". Because of code patching restrictions, fast tracepoints cannot be inserted anywhere in the code. GDB will report the times when a fast tracepoint fails to be inserted; a slow tracepoint can be used when a fast tracepoint cannot. Fast tracepoints, to remain highly efficient, do not allow the 'while-stepping' action. A Tracing Experiment is the time during which tracepoints are active and data is collected. Trace State Variables are like convenience variables of GDB but are managed by the gdbserver. This allows for these variable to still be used even if the connection with GDB is broken. Observer-mode is a state that can be enabled/disabled by the user to prevent GDB from performing intrusive actions, such as setting real breakpoints, writing to memory, etc. When doing tracing, this mode can be used to protect a target against such intrusive actions. Global Tracepoint Actions are tracepoint actions that are to be performed by every running tracepoint. A Trace Record is the data collected when a tracepoint has been service once. Proposed DSF-GDB behavior: ========================= Control ------- Launch: - The existing launch configuration are to be used to perform tracing. Specifically, the Attach launch for a Remote target. Controlling tracepoints: - Tracepoints shall be tracked in the breakpoint view using a new icon. - Tracepoints shall be shown in the Editor margin and the DSF Disassembly view margin using a new icon. - If a tracepoint and breakpoint are set at the same location, the standard multiple marker approach shall be used. - As for breakpoints, context menu items in the editor and disassembly view shall be added to: o toggle tracepoint o enable/disable tracepoint o open tracepoint properties - Double-click on the margins will continue to set breakpoints - Tracepoints shall be created/deleted/enabled/disabled similarly as breakpoints - As for breakpoints, tracepoints will be created with no attributes, conditions or actions. The user can then use the Tracepoints Properties pop-up to seset such things. This is actually better than breakpoints because tracepoints are not activated right away, so the user has plenty of time to set tracepoints properties before that tracepoint is actually used. - 'skip all breakpoints' does not provide any added functionality to tracepoints. This is because stopping a trace experiment does the same thing. Furthermore, there is no value in running a tracing experiment if all tracepoints are to be skipped. Therefore, 'skip all breakpoints' shall not affect tracepoints. - tracepoints have an extra state that breakpoints do not have: "installed in GDB but not active on the target". So, tracepoints can be any of the following states, at the same time: o enabled/disabled. This shall be shown as for breakpoints o installed/not installed. This is when eclipse has instructed GDB to create the tracepoint. It will be shown as for breakpoints (little check-mark decorator) o active/inactive. This is when the tracepoint has been installed in GDB but not been sent to the target (gdbserver). This happens, for example, when no tracing experiment is running. Showing a tracepoint as active shall be done with a new decorator such as a little "play button" triangle. Tracepoint properties: - Tracepoints shall have a property pop-up like for breakpoints. - Tracepoints properties shall allow the user to set: o passcount (similarly to the breakpoint ignorecount) o conditions, in a free-form text box, like breakpoint conditions o actions shall be set using the breakpoint action scheme. o parsing conditions and actions for validation will be done by GDB as soon as they are set. Any error will be reported to the user immediately using a pop-up - DSF-GDB shall provide a way to open a Global Tracepoint Properties pop-up to modify Global Tracepoint Actions and other global attributes of tracepoints. This pop-up will be based on the Tracepoint Properties pop-up. Retrieving the list of tracepoints: - because tracepoints are not removed from a target when we stop a debugging (tracing) session, recreating such tracepoints when re-connecting to a running target, is different than for breakpoints. GDB's final support for this is still unclear. This point will need more thought. - loading and saving tracepoints from and to file shall also be investigated, based on GDB's final support Tracing Experiment Control: - DSF-GDB shall provide a way to start and stop a tracing experiment GDB Console - DSF-GDB shall support tracepoints within the GDB console. I believe this should already be working. Tracing Status: - A way to report the current tracing status will be given to the user. Currently, we are contemplating a new "Tracing Status View". This view would show information such as: o Is a tracing experiment running o when was the tracing experiment started o how much tracing data has been collected up to now o etc Observer-mode: - DSF-GDB will gray-out any actions that will not be accepted when observer-mode is active. - DSF-GDB will provide a way to enable/disable observer-mode Visualization of data --------------------- Trace data shall be possible to examine using DSF-GDB. Two visualization methods will be provided: 1- text dump to the console 2- using the existing debugging views. This simply means that we will show any collected data, as if we were currently debugging the program. Navigation within trace data: - DSF-GDB shall support navigation through time across all trace records, one record at a time, forwards and backwards. - DSF-GDB shall support navigation through time for a specific tracepoints, one record at a time, forwards and backwards. - The source code location shall be updated in the Editor and Disassembly view, as navigation progresses, similarly to single stepping. - DSF-GDB will provide a way to specify where to start data navigation such as: o starting at the first record o starting at a specified timestamp o starting at the first record collected at a specified line or address Visualizing Trace Data as a text dump: - DSF-GDB shall provide a way for a user to dump the current trace record to the console - DSF-GDB shall provide a way for a user to dump all trace records to the console - DSF-GDB shall provide a way for a user to dump a range of trace records to the console - DSF-GDB shall provide a way to save the console output to file (this is actually a missing feature already) Visualizing Trace Data using the existing debugging views: - DSF-GDB shall allow the user to display a trace record collected information in the debugging views. If certain information is not available (not been collected), the views will show that the data is not available. I will need to prototype this before fully understanding how it will look. Offline examination of data: - DSF-GDB shall allow a user to save all trace data to a file. - DSF-GDB shall allow a user to examine trace data that is stored on file. This is similar to the Post-Mortem launch. A new launch may be needed for this, unless the post-mortem launch can be re-used.
The proposed approach is very similar to what we were planning to do for the trace visualization. I was also considering to have a special element (as a member of launch, target and process hierarchy) in the Debug view that would represent a running tracing experiment. This element would contribute the trace related actions (tstart, tstop, snapshot navigation commands, etc) to the view and have a console associated with it.
(In reply to comment #1) > The proposed approach is very similar to what we were planning to do for the > trace visualization. I was also considering to have a special element (as a > member of launch, target and process hierarchy) in the Debug view that would > represent a running tracing experiment. This element would contribute the trace > related actions (tstart, tstop, snapshot navigation commands, etc) to the view > and have a console associated with it. Kind of like the inferior entry, right? I like that.
Wow this is quite the write up. At this point, I would only request that tracepoints be implemented like breakpoints in that the tracepoint objects are declared in the org.eclipse.cdt.debug.* plugins, and they are consumed by the specific debugger (i.e. DSF-GDB). But I'm guessing that this is what you were planning anyway. I will try to review your proposals and patches and give you my feedback as much as I can.
(In reply to comment #3) > Wow this is quite the write up. Yeah... It is probably too long for anyone to read right away, but I felt it was good to have a record of what was planned. > At this point, I would only request that > tracepoints be implemented like breakpoints in that the tracepoint objects are > declared in the org.eclipse.cdt.debug.* plugins, and they are consumed by the > specific debugger (i.e. DSF-GDB). But I'm guessing that this is what you were > planning anyway. It is funny you mention that. I was actually wondering about that today, was about to ask on the list, but then decide to do it all in DSF-GDB to avoid affecting other plugins. But since you also think the underlying support should be generic, I will try to include it in the cdt.debug.* plugins. > I will try to review your proposals and patches and give you my feedback as > much as I can. As always, I really appreciate your help. Thanks in advance.
(In reply to comment #3) > I will try to review your proposals and patches and give you my feedback as > much as I can. I already have a question ;-) From a platform perspective, what do you recommend I use for the new menu items: commands or actions? You made me realize that commands are still synchronous which is a problem for DSF-GDB. However, will you be able to get them to be asynchronous by the 3.6 release? Or should I simply revert to using actions? Thanks
(In reply to comment #4) > Yeah... It is probably too long for anyone to read right away, but I felt it > was good to have a record of what was planned. Oh I read it all :-) (In reply to comment #5) > I already have a question ;-) > From a platform perspective, what do you recommend I use for the new menu > items: commands or actions? You made me realize that commands are still > synchronous which is a problem for DSF-GDB. However, will you be able to get > them to be asynchronous by the 3.6 release? Or should I simply revert to using > actions? Could you be more more specific? What are the commands to be used for?
(In reply to comment #2) > (In reply to comment #1) > Kind of like the inferior entry, right? Exactly.
(In reply to comment #6) > Could you be more more specific? What are the commands to be used for? I'll need new commands/actions for things like - Toggle tracepoint - Enable/Disable tracepoint - Tracepoint properties... and then all the navigation menus to go through the collected trace data.
(In reply to comment #8) > (In reply to comment #6) > I'll need new commands/actions for things like > - Toggle tracepoint > - Enable/Disable tracepoint > - Tracepoint properties... As a first step, I thought I would save myself time and use the new extension-point org.eclipse.debug.ui.toggleBreakpointsTargetFactories. If I understand correctly, this is meant to allow me to dynamically select which kind of breakpoints are being used. Using this, and by defining a new breakpoint type for Tracepoints, I could easily re-use the existing breakpoint menus. I'm not sure if this is something we'll want to keep in the final tracepoint solution, but it will help me get something working faster.
Created attachment 143070 [details] Icon for tracepoint object Proposed icon for a tracepoint
Created attachment 143071 [details] Icon for disabled tracepoint object Proposed icon for disabled tracepoint object
Created attachment 143072 [details] Icon for installed decorator Proposed icon for installed decorator for a tracepoint
Created attachment 143073 [details] Icon for disabled installed decorator Proposed icon for disabled installed decorator for a tracepoint
I've reduced the scope of this bug to the new GDB tracepoint support (GDB 7.0). There are too many differences to do both supports at once. I've opened Bug 285291 to track any work done to support tracepoints with older GDBs.
Created attachment 143191 [details] First prototype I'm going on my paternity leave for the next five weeks, so I'm posting what I have done up to now. This patch uses the extension point org.eclipse.debug.ui.toggleBreakpointsTargetFactories to share breakpoint actions with tracepoints. What is currently working with this patch is: - Creating/Deleting tracepoints - Special visual icons for tracepoints - Enable/Disable tracepoints - Conditions for tracepoints - Full tracepoint support in gdb console When I return, I will look into actions, trace state variables, tracing experiment and visualization. There is also a one line change in the patch for platform (see bug 285215).
Oh, this last patch is a prototype and gets things working for DSF-GDB. I didn't do any cleanup and stuff like making sure there is no impact to CDI, etc. That will come later.
Created attachment 143332 [details] Alt. icon for tracepoint object (In reply to comment #10) > Created an attachment (id=143070) [details] > Icon for tracepoint object > > Proposed icon for a tracepoint > Using only color to distinguish an icon is a problem because it's not accessible for color-blind people. The attached is the icon that we use to represent a tracepoint. I like to use the regular breakpoint image as a background for all different breakpoint types as it provides some visual consistency. On the down-side it can also look cluttered.
I'm back :-) (In reply to comment #17) > Created an attachment (id=143332) [details] > Alt. icon for tracepoint object > Using only color to distinguish an icon is a problem because it's not > accessible for color-blind people. Good point. > The attached is the icon that we use to > represent a tracepoint. I like to use the regular breakpoint image as a > background for all different breakpoint types as it provides some visual > consistency. On the down-side it can also look cluttered. Thanks. I'll need to try to see for myself, but I wonder if this icon looks ok with the different decorators? There is the installed decorator and the conditional decorator, which will be used. Also, a new decorator for active/inactive state. So, at least three of the four corners could have a decorator, and I'm worried about the two top corners of this icon.
(In reply to comment #17) > I like to use the regular breakpoint image as a > background for all different breakpoint types as it provides some visual > consistency. On the down-side it can also look cluttered. I tried it and there is some clutter, but it's not too bad. Do you have the disabled icon that matches the one you attached? Thanks
Created attachment 148639 [details] Alt. disabled icon for tracepoint The disabled icon to match the icon attached by Pawel.
Created attachment 151311 [details] Proposed overlay for active tracepoint (enabled) This overlay is meant to be used when a tracepoint is currently part of a running trace experiment.
Created attachment 151312 [details] Proposed overlay for active tracepoint (disabled) This overlay is meant to be used when a disabled tracepoint is currently part of a running trace experiment. It is not entirely clear how this will happen (diabled tracepoint but part of tracing), but I'm putting it here just in case.
Created attachment 151321 [details] Phase-one design proposal To make the commit process easier, I have divided the tracepoint effort into different phases. I was worried that trying to get everything approved at once would generate so much discussion that it would delay things too much; instead, going by small increment should help reaching a consensus faster. This attachment is a design document for the first phase.
(In reply to comment #23) > Phase-one design proposal The proposal makes perfect sense to me. One suggestion I may add, which I think also applies to CDT breakpoints, is that it would be good to have an additional action in the CDT editor gutter: "Add Tracepoint...". This action would then open a dialog and allow user to set the tracepoint options before creating the tracepoint. The implementation of such an option would be tricky, because it would require that the breakpoint object not be created until after the dialog is closed. Also, on the DSF implementation side I'm curious what you are planning (maybe DSF part should be in a separate bug). One option I was thinking of is that a separate tracepoint service could be instantiated created with the same interface as the breakpoints service (since it would be essentially identical in functionality). Then a separate breakpoint mediator could be created just for tracepoints as well. This way, if tracepoints were not supported by a given GDB back end, the tracepoint services would simply not be instantiated.
(In reply to comment #24) > (In reply to comment #23) > > Phase-one design proposal > > The proposal makes perfect sense to me. Thanks for looking at it already. > One suggestion I may add, which I > think also applies to CDT breakpoints, is that it would be good to have an > additional action in the CDT editor gutter: "Add Tracepoint...". This action > would then open a dialog and allow user to set the tracepoint options before > creating the tracepoint. The implementation of such an option would be tricky, > because it would require that the breakpoint object not be created until after > the dialog is closed. This is a valuable feature that I would like to see for breakpoints. In the case of GDB tracepoints, it is not really necessary. The reason is that a tracepoint doesn't actually take effect until a trace-experiment is started. Also, GDB does not allow to add a tracepoint to an running trace-experirment. What that means is that a tracepoint can be created (empty) and will have not effect. The user can then add commands, conditions and change attributes. After that is done for all tracepoints, the user can start the trace-experiment. It is only at that point that tracepoints will actually have an impact on the inferior. So, unlike breakpoints, there is not as clear a benefit in creating a GDB tracepoint with all its information. However, for backends that allow adding tracepoints immediately, as tracing is on-going, then I agree that this feature would be very nice. I suggest this enhancement be part of another bug. > Also, on the DSF implementation side I'm curious what you are planning (maybe > DSF part should be in a separate bug). Might as well discuss it here since the currently planned full support of tracepoint will be done for DSF-GDB. > One option I was thinking of is that a > separate tracepoint service could be instantiated created with the same > interface as the breakpoints service (since it would be essentially identical > in functionality). I hadn't thought about that solution. It is interesting. What I started doing was to extend the existing breakpoint service to support tracepoint. The changes are actually pretty small because the MI interface that is going to be used for tracepoints re-uses the breakpoint MI commands For example, creating a tracepoint is with "-break-insert -a". Enabling/disabling tracepoint is through the exact same bp commands as for a traditional bp. There would be some benefits in separating the two services, but I'm not convinced those would outweigh the duplication of code. If you have strong feelings about this, please let me know. Or maybe, once I post the proper patch, you can see if you like the two services together or not. > Then a separate breakpoint mediator could be created just > for tracepoints as well. This way, if tracepoints were not supported by a > given GDB back end, the tracepoint services would simply not be instantiated. DSF-GDB does not use the BreakpointMediator. It uses the MIBreakpointsManager. I'm not familiar with the bp mediator, but I hadn't planned on making this migration because the tracepoint effort was large enough already :-)
This looks good to me. It looks like the meat of the feature will come in subsequent rounds, and there will be much more to comment on then :-) I just have one minor suggestion. You indicate that the 'Tracepoints' breakpoint-type selection won't be visible when the feature is not supported, and also when supported but running with a version of GDB that doesn't support tracepoints. However, as a breakpoint/tracepoint can be set in the editor before launching a debug session, so the user will likely see the option at some point. To then hide it during a debug session will be confusing, in my opinion. I can see the user frantically searching all around thinking "I know I saw that option somewhere." I think it would be better to disable the option than to hide it.
(In reply to comment #26) > This looks good to me. It looks like the meat of the feature will come in > subsequent rounds, and there will be much more to comment on then :-) That is what I'm afraid of, which is why I wanted to get this part in by itself :-) > You indicate that the 'Tracepoints' breakpoint-type selection won't be visible > when the feature is not supported, and also when supported but running with a > version of GDB that doesn't support tracepoints. However, as a > breakpoint/tracepoint can be set in the editor before launching a debug > session, so the user will likely see the option at some point. To then hide it > during a debug session will be confusing, in my opinion. I can see the user > frantically searching all around thinking "I know I saw that option somewhere." > I think it would be better to disable the option than to hide it. Yes, this part is a bit tricky. When I first implemented things, I didn't really pay attention to turning things off when they were not supported. I am trying different things out right now and will post a more detailed behavior (that will try to address your point).
(In reply to comment #22) Overall looks good, but a couple of thoughts. As far as I understand the proposed common property page is intended to cover all tracepoint types (not the GDB tracepoints). If so, isn't it better to keep the list of properties to minimum and let the models add their own properties. In the past I had trouble with the common properties like "ignore-count", "condition" for breakpoints. For some cases it is not clear if these properties are available without connecting to the target. A minor comment. Naming the command group "Tracing" is too general: this implementation covers only a specific type of tracing. I would suggest "Tracepoints".
(In reply to comment #28) > (In reply to comment #22) > Overall looks good, but a couple of thoughts. > As far as I understand the proposed common property page is intended to cover > all tracepoint types (not the GDB tracepoints). If so, isn't it better to keep > the list of properties to minimum and let the models add their own properties. > In the past I had trouble with the common properties like "ignore-count", > "condition" for breakpoints. For some cases it is not clear if these properties > are available without connecting to the target. I'm glad you brought that up. I was wondering how come noone had issues with some of the breakpoint properties. But those are global to cdt.debug.ui right? I planning on re-using most of them (condition, ignore-count, etc) (by sharing the proterty page class between breakpoints and tracepoints (and adding the passcount through an if-check). If I understand correctly, you suggest that for tracepoints, I create a new property page class in cdt.debug.ui and keep it to a minimum of content. I would then extend that page in dsf.gdb.ui to add the content. Is that right? I'm up for that. > A minor comment. Naming the command group "Tracing" is too general: this > implementation covers only a specific type of tracing. I would suggest > "Tracepoints". As long as the name "Tracepoints" can still be understood to mean that the action set controls other things like start/stop tracing and looking at the result of a trace, I don't mind changing the action set name. Does "Tracepoints" cover that extended meaning, for you, as a use? Thanks for the feedback
(In reply to comment #29) > I'm glad you brought that up. I was wondering how come noone had issues with > some of the breakpoint properties. But those are global to cdt.debug.ui right? That's right and I am the one who put it there. That's why I brought this up. > If I understand correctly, you suggest that > for tracepoints, I create a new property page class in cdt.debug.ui and keep it > to a minimum of content. I would then extend that page in dsf.gdb.ui to add > the content. > Is that right? I'm up for that. That's correct. But let's wait for more comments. > > A minor comment. Naming the command group "Tracing" is too general: this > > implementation covers only a specific type of tracing. I would suggest > > "Tracepoints". > As long as the name "Tracepoints" can still be understood to mean that the > action set controls other things like start/stop tracing and looking at the > result of a trace, I don't mind changing the action set name. > Does "Tracepoints" cover that extended meaning, for you, as a use? It probably doesn't, but "Tracing" will definitely collide with TPTP and some other completely unrelated projects. Does it make sense to have separate action sets for trace visualization, control and tracepoints? I have been thinking of implementing a general trace visualization framework (sounds a bit scary) that provides generic commands for next/previous snapshot, go to and maybe even a support for watchpoints. > Thanks for the feedback You're very welcome
(In reply to comment #30) > (In reply to comment #29) > > I'm glad you brought that up. I was wondering how come noone had issues with > > some of the breakpoint properties. But those are global to cdt.debug.ui right? > > That's right and I am the one who put it there. That's why I brought this up. > :-) > > If I understand correctly, you suggest that > > for tracepoints, I create a new property page class in cdt.debug.ui and keep it > > to a minimum of content. I would then extend that page in dsf.gdb.ui to add > > the content. > > Is that right? I'm up for that. > > That's correct. But let's wait for more comments. Ok. > > > A minor comment. Naming the command group "Tracing" is too general: this > > > implementation covers only a specific type of tracing. I would suggest > > > "Tracepoints". > > As long as the name "Tracepoints" can still be understood to mean that the > > action set controls other things like start/stop tracing and looking at the > > result of a trace, I don't mind changing the action set name. > > Does "Tracepoints" cover that extended meaning, for you, as a use? > > It probably doesn't, but "Tracing" will definitely collide with TPTP and some > other completely unrelated projects. > Does it make sense to have separate action sets for trace visualization, > control and tracepoints? How about this: for now, I'll make the action set be "Tracepoints". As I start proposing the rest of the feature, we can adapt this, based on people's comments. > I have been thinking of implementing a general trace visualization framework > (sounds a bit scary) that provides generic commands for next/previous snapshot, > go to and maybe even a support for watchpoints. That's sounds cool! If that becomes available, I'll migrate the tracing I'm about to do, to this framework. Maybe my implementation can even help in your design, as you will get a concrete example.
(In reply to comment #31) > That's sounds cool! > If that becomes available, I'll migrate the tracing I'm about to do, to this > framework. Maybe my implementation can even help in your design, as you will > get a concrete example. Thank you. I don't want to promise anything after the very bad experience with disassembly. Are you going to post a design document for the GDB-based visaulization?
(In reply to comment #32) > (In reply to comment #31) > Are you going to post a design document for the GDB-based visaulization? Yes I will do that. Some functionality from GDB is still not clear, so I have to wait a bit, but I'm hoping to have something this month.
Question for more experienced people than I: can anyone confirm that it makes sense that I create all three of cLineTracepoint cAddressTracepoint cFunctionTracepoint just like it is done for breakpoints? This is because a tracepoint can also be set to a line of code, an address, or a function. Thanks
In the platform meeting we quickly brushed on the following issue: if I create a Tracepoint in a DSF-GDB launch, and then I launch a CDI-GDB launch, I would see CDI-GDB treat the Tracepoint as a Breakpoint and create it in the backend I believe my problems stems from the fact that I wanted to make a Tracepoint simply extended the current Breakpoint classes. Something like: class CTracepoint extends AbstractLineBreakpoint implements ICTracepoint But I think this is too much re-used. I believe e-using a LineBreakpoint makes CDI-GDB treat a tracepoint as a breakpoint. I could change a bit of CDT code to fix this, but I'm worried about other debugger integrations that may also trigger on a LineBreakpoint. I see that a CWatchpoint simply extends CBreakpoint and that seems to work. I guess I can do that. It's too bad though, because I'll have to duplicate a lot more code (LineTracepoint, AddressTracepoint, FunctionTracepoint) Any opinions if I can simply update the CDT code to do more filtering or if this will cause me problems with other integrations?
(In reply to comment #35) Marc, maybe I missing something but we can filter ICBreakpoints that are not ICTracepoints in CBreakpointManager. I don't think it will affect any other implementation.
(In reply to comment #36) > (In reply to comment #35) > Marc, maybe I missing something but we can filter ICBreakpoints that are not > ICTracepoints in CBreakpointManager. I don't think it will affect any other > implementation. Yes, that is what I was thinking, but I don't quite understand how users of CDT re-use the code and stuff. Will they have the same problem of creating a Tracepoint as a breakpoint? Or do they use the CBreakpointManager, and therefore will be protected?
(In reply to comment #37) > Yes, that is what I was thinking, but I don't quite understand how users of CDT > re-use the code and stuff. Will they have the same problem of creating a > Tracepoint as a breakpoint? Or do they use the CBreakpointManager, and > therefore will be protected? If somebody extends ICBreakpoint it will be treated as "legitimate" breakpoint by CDT that's why the CDI implementation tries to set it. That's the intended use of ICBreakpoint. CBreakpointManager is an internal class and shouldn't be used by implementations. ICTracepoint is a new interface and adding it to CDT makes the filtering legal.
(In reply to comment #38) > (In reply to comment #37) > If somebody extends ICBreakpoint it will be treated as "legitimate" breakpoint > by CDT that's why the CDI implementation tries to set it. That's the intended > use of ICBreakpoint. > CBreakpointManager is an internal class and shouldn't be used by > implementations. > ICTracepoint is a new interface and adding it to CDT makes the filtering legal. I wasn't clear in my question. If another debugger integration gets a breakpointAdded() call with an ICTracepoint (which extends ICBreakpoint), won't it try to create it as a normal breakpoint? Unless that integration adds a check to ignore ICTracepoint, like we're proposing to do in CBreakpointManager. But how will integrators know about this requirement to ignore ICTracepoint?
(In reply to comment #39) > I wasn't clear in my question. > If another debugger integration gets a breakpointAdded() call with an > ICTracepoint (which extends ICBreakpoint), won't it try to create it as a > normal breakpoint? Unless that integration adds a check to ignore > ICTracepoint, like we're proposing to do in CBreakpointManager. But how will > integrators know about this requirement to ignore ICTracepoint? I see. Sorry I didn't understand the question. I don't see how to avoid this without duplicating the implementation of ICBreakpoint and all its subclasses :(
(In reply to comment #40) > (In reply to comment #39) > > I wasn't clear in my question. > > If another debugger integration gets a breakpointAdded() call with an > > ICTracepoint (which extends ICBreakpoint), won't it try to create it as a > > normal breakpoint? Unless that integration adds a check to ignore > > ICTracepoint, like we're proposing to do in CBreakpointManager. But how will > > integrators know about this requirement to ignore ICTracepoint? > > I see. Sorry I didn't understand the question. I don't see how to avoid this > without duplicating the implementation of ICBreakpoint and all its subclasses > :( I'll post the first patch without addressing this issue (since it is easier) and I'll then bring up the issue to the cdt-dev list to see it people feel it should be addressed. In the platform meeting, Darin mentioned that the JDT wouldn't be affected because each JDT bp is mapped to the debugModelId (if I understood correctly). Couldn't we do the same thing and use the DSF-GDB debugModelId?
(In reply to comment #26) > You indicate that the 'Tracepoints' breakpoint-type selection won't be visible > when the feature is not supported, and also when supported but running with a > version of GDB that doesn't support tracepoints. However, as a > breakpoint/tracepoint can be set in the editor before launching a debug > session, so the user will likely see the option at some point. To then hide it > during a debug session will be confusing, in my opinion. I can see the user > frantically searching all around thinking "I know I saw that option somewhere." > I think it would be better to disable the option than to hide it. Ok, I have two options and I can't decide. 1- when in the CEditor, have both bp types (breakpoint, tracepoint) visible at all times. That means when there is no launch, when there are multiple launches (with or without DSF ones), etc In this case, a CDI launch will put an error marker where the tracepoint is being created what will say "Tracepoints not supported" 2- only show the tracepoint type when currently in a DSF-GDB debug session. This means that the user will ONLY see tracepoints when the active debug context is a DSF-GDB debug context. This also means that the user will NOT see tracepoints (or be able to set them) in the editor, before starting a debug session. This addresses John's concern, but may be considered bad if we want users to set tracepoints before launching. Opinions? Thanks
(In reply to comment #42) I think #2 is too restrictive. Users should be able to set tracepoints before their debug session, as they can for breakpoints. #1 seems reasonable. I would still like to see the menu item disabled once the debug session is ongoing, though. I guess that would require a change to the platform, and Pawel is going to consider that.
(In reply to comment #43) > (In reply to comment #42) > > I think #2 is too restrictive. Users should be able to set tracepoints before > their debug session, as they can for breakpoints. #1 seems reasonable. I would > still like to see the menu item disabled once the debug session is ongoing, > though. I guess that would require a change to the platform, and Pawel is going > to consider that. That is actually easier to implement :-) I'll do it this way for now. We can see how it feels or if someone else has an opinion.
As there does not seem to be a way to programmatically check if an actionSet is active, I'm marking this bug as dependent on bug 294553
(In reply to comment #30) > > If I understand correctly, you suggest that > > for tracepoints, I create a new property page class in cdt.debug.ui and keep it > > to a minimum of content. I would then extend that page in dsf.gdb.ui to add > > the content. > > Is that right? I'm up for that. > > That's correct. But let's wait for more comments. I've tried this and ran into a potential problem. What I did was to create the property page in dsf.gdb.ui. That way, I can make the content of the page GDB-specific. However, I thought it would be wise to attach that property page to the dsf-gdb debugModelId, to avoid having this property page be shown for some other debugger. This last point makes it so that you can only see the property page during a DSF-GDB debug session. This is a problem when setting tracepoint before launching a debugging session. John felt that it would be nice to be able to add tracepoints in the editor before launching the debugger (which I tend to agree with), but then we'd need a property page too... Unless the property page is declared globally in cdt.debug.ui, I don't see a way to do this without risking having multiple property pages shown at the same time (one for each debugger that contributes it). What do you think, should I make the tracepoint property page global like for breakpoints (that page will contain: enabled, condition, ignore-count and the tracepoint-specific "pass-count"). Thanks for any suggestions. P.S. Once that issue is solved, I'm ready to post the patch for phase one of tracepoints.
(In reply to comment #46) If ICTracepoint interface is in cdt.debug.ui then we need a global property page. I am just not sure about the properties you listed: as I mentioned I had problems for the targets that didn't support some of it. I was thinking of moving some of the listed properties to the model-specific pages. For example, GDB doesn't support pass count and having it on the global property page will be confusing. BTW, I don't understand why do you need a dsf-gdb session to display a dsf/gdb specific property page? If dsf.gdb.ui plug-in is installed and active the property pages contributed by it should be visible. Am I missing something?
(In reply to comment #47) > (In reply to comment #46) > > If ICTracepoint interface is in cdt.debug.ui then we need a global property > page. I am just not sure about the properties you listed: as I mentioned I had > problems for the targets that didn't support some of it. I was thinking of > moving some of the listed properties to the model-specific pages. For example, > GDB doesn't support pass count and having it on the global property page will > be confusing. The problem is that if you want to set tracepoints before launching, then the properties that you are interested in are entirely dependent on which type of which type of session you will use. We cannot tell this in advance. Say I launch eclipse and plan on tracing an app using DSF-GDB. I start creating my tracepoints first, but when I want to set GDB-specific properties for that tracepoint, they are not shown in the property page. Oh wait, unless you mean... see below please. > BTW, I don't understand why do you need a dsf-gdb session to display a dsf/gdb > specific property page? If dsf.gdb.ui plug-in is installed and active the > property pages contributed by it should be visible. Am I missing something? Say we are talking about the "Common" property page. I had assumed that there would be one of those shown at a time. When running DSF-GDB you would get the page contributed by DSF-GDB, while when running CDI, you would get the CDI (if it contributed one). But the way to do this is to associate a property page contribution with a debugModelId, but when there are no debug sessions, there are no modelId, so no page are being shown. Unless you are suggesting that there be multiple "Common" pages shown at the same time? Like "Main Common", "DSF-GDB common", etc? This would solve the problem. However, I find something like this very cumbersome and confusing for the user... But maybe that is not what you meant at all? P.S. It's ignore count GDB does not support, although this may change...
(In reply to comment #48) Marc, what do you mean by "running DSF-GDB"? You don't need a running debug session to contribute a property page. If dsf.gdb.ui is installed the property pages that come with it are available.
(In reply to comment #49) > (In reply to comment #48) > Marc, what do you mean by "running DSF-GDB"? You don't need a running debug > session to contribute a property page. If dsf.gdb.ui is installed the property > pages that come with it are available. Below is the (pseudo-code) extension I was thinking of adding for the Common page for tracepoints from DSF-GDB. The filter tag tells it to only display if the activeContext is part of DSF-GDB. so, this page will *only* show if we have a DSF-GDB session running and selected. If I remove the filter tag, things will work, but what will happen when, say CDI also provides a "Common" page for tracepoints? Both pages will be shown a the same time, no? That is why I thought I needed the filter. <page class="GDBTracepointPropertyPage" id="dsf.gdb.common" name="Common"> <filter name="debugModelId" value="org.eclipse.cdt.dsf.gdb"/> <enabledWhen> <adapt type="org.eclipse.cdt.debug.core.model.ICTracepoint"/> </enabledWhen> </page>
(In reply to comment #50) Marc, I suggest to have one "Common" property page contributed cdt.debug.ui. DSF and CDI can contribute additional pages with or without filters. All we need is to choose the properties that are common for all models. For instance, pass count is not a common property.
(In reply to comment #51) > (In reply to comment #50) > Marc, I suggest to have one "Common" property page contributed cdt.debug.ui. > DSF and CDI can contribute additional pages with or without filters. > All we need is to choose the properties that are common for all models. For > instance, pass count is not a common property. Thanks for the input Mikhail. I just want to make sure we are on the same page (no pun intended :-)). I'm thinking is that we may end up with: 1- one "Common" page in cdt.debug.ui. 2- one "Common (DSF-GDB)" in dsf.gdb 3- maybe later, one "Common (CDI-GDB)" in the cdi plugin 4- maybe for EDC, on "Common (EDC)" in the edc plugins etc If we don't use filters, all four pages will show all the time. I don't like that too much. How will the user know which one to use? If we use filters, #1 will show all the time, #2 only when using DSF-GDB, #3 only for CDI-GDB, #4 only for EDC. That is nice. Except that if I want to set a tracepoint before I start debugging, then I will only have access to page #1. So, if I want to set a passcount, I will have to start my DSF-GDB session before setting it. Maybe I'm misunderstanding something fundamental about the property page contributions?
(In reply to comment #52) I agree, it's not very nice, but I wouldn't use filters for the common model pages. But it shouldn't affect the implementation - it's only a line in the plugin.xml file. We can discuss it later.
(In reply to comment #53) > (In reply to comment #52) > I agree, it's not very nice, but I wouldn't use filters for the common model > pages. > But it shouldn't affect the implementation - it's only a line in the plugin.xml > file. We can discuss it later. Ok
Created attachment 152121 [details] Phase one patch Finally, here is the patch for phase one of tracepoints. I'm hoping people can give it a try. I'm very interested in comments. I'm hoping to check this functionality in relatively soon, so that I can build on top of it with phase two. Things to know: 1- The patch allows to create/delete, enable/disable, set/modify properties of tracepoints in DSF-GDB. 2- The patch ONLY works with GDB 7.0 (older GDBs are not part of this effort) 3- After applying the patch the two new tracepoints icons must be added manually. Just save the two attachments of this bug "Alt. icon for tracepoint object" and "Alt. disabled icon for tracepoint" and save them as org.eclipse.cdt.debug.ui/icons/elcl16/trcp_obj.gif and org.eclipse.cdt.debug.ui/icons/dlcl16/trcpd_obj.gif respectively. Don't forget to refresh your plugin. 4- To be able to toggle tracepoints, one must turn on the "Tracepoints" action set in "Customize perspective...". Then choose the right Breakpoint type from the "Run..." menu or the margin of the CEditor. This action set will hide the choice of toggling tracepoints, but you will need the latest org.eclipse.debug.core/ui to make this work (bug 294553) 5- Tracepoints can be toggle before any debug session or during a debug session. 6- Tracepoints will be properly set for DSG-GDB using GDB7.0. Any other GDB, or if using CDI, a problem marker will appear where the tracepoint was toggled. 7- Currently, we cannot create a tp where there is a bp and vice versa. Toggling a tp where there is a bp, will remove the bp, and vice versa. This can maybe be improved later. 8- Only the "Common" property page for tracepoints is part of phase one (this patch). The page is entirely contributed by DSF-GDB. This solution is still under discussion. 9- The patch also has some JUnit tests. 10- Creating bp/tp is done in CDIDebugModel.java. Kind of weird that its called 'CDI' 11- The way Tracepoints are implemented they are extending LineBreakpoint. I've put a check to filter the tracepoints from the CBreakpointManager, but other debugger integration, may now receive a Tracepoint and treat it as a LineBreakpoint, if it doesn't consciously add a check for tracepoint. I'm not sure if this is a big issue or not 12- One can use the DSF-GDB console to do everything else that GDB supports about tracepoints that is not yet supported by this patch (tstart/tstop/tstatus etc) 13- I think the CDT core parts of this patch are pretty clean. But some DSF-GDB parts have a bunch of commented stuff; this is because those will change with the next phases of this feature, so I chose to leave them in short term. Thanks in advance for feeback.
Oh yeah, and all this is supported for the CEditor and the DSF Disassembly view.
I just thought that not everyone has GDB 7.0. It is officially released and very easy to build. Some may find it even easier to download it pre-built for Windows. To download a binary of GDB 7.0 for windows (MinGW): http://sourceforge.net/projects/mingw/files/ where it is under the "GNU Source-level Debugger" folder. or directly at http://sourceforge.net/projects/mingw/files/GNU%20Source-Level%20Debugger/GDB-7.0/gdb-7.0-mingw32-bin.tar.gz/download For linux, download from ftp://sourceware.org/pub/gdb/releases/ choose the 7.0 file of your choice (bz2 is the smallest) untar in some directory (tar xf <file>) cd src ./configure make That's it. You will then find gdb under src/gdb/gdb
Unless someone disagrees, I will commit the first phase patch today as it is well isolated from future work. Proposal for the rest of the work is coming soon.
I finally committed "Phase one patch"
I've just created a wiki page to describe the Tracepoint work http://wiki.eclipse.org/CDT/designs/Tracepoints
Created attachment 155531 [details] Proposed StartTracing icon
Created attachment 155533 [details] Proposed StopTracing icon
Created attachment 155535 [details] Proposed TraceControlView icon
I've committed the three icons "Proposed StartTracing icon", "Proposed StopTracing icon" and "Proposed TraceControlView icon" to make dealing with patches easier, since patches don't store icons. They are part of org.eclipse.cdt.dsf.gdb.ui. Those icons can easily be changed based on comments.
Created attachment 155628 [details] Phase-two design proposal 4 pages for phase two design document. It covers Tracepoint Actions, the new Trace Control View, and Start/Stop/Status/Save of tracing. With this phase, a user will be able to create tracepoints, trace the system, then collect the trace data for offline visualization. The last major part is the actual visualization of trace data in the CDT. As this is also a stand-alone feature, I will cover it in a phase three. Comments most welcome. Patch coming soon.
Created attachment 155629 [details] Proposed SaveTraceData icon Icon to save trace data to a file
Comment on attachment 155628 [details] Phase-two design proposal I'm making changes to my phase-two design proposals, because it did not make sense to have Global Tracepoint Actions as a preference. I will post a new phase-two proposal shortly.
Created attachment 156499 [details] Phase-two enhanced proposal Here is the design proposal for phase two. It talks about: 1- Tracepoint actions Support in main CDT, but the new specific action types will be in DSF-GDB 2- Global Tracepoint actions In DSF-GDB only 3- A new TraceControl view In DSF-GDB only 4- Start/Stop/Status of Tracing Start/Stop will be commands in main CDT, which will be handled in DSF-GDB Status will only be in DSF-GDB 5- Handling of Trace State Variables. In DSF-GDB only 6- Saving Trace Data A command in main CDT, which will be handled in DSF-GDB The patch is almost ready.
(In reply to comment #68) Marc, I don't think there is a document in the latest patch. Am I missing something?
(In reply to comment #69) > (In reply to comment #68) > Marc, I don't think there is a document in the latest patch. Am I missing > something? It's a Open Office document. If you select the attachment you should be able to download it. I've tried it now and it worked. Let me know if you still have problems and I can email it to you.
(In reply to comment #70) Marc, regarding the Trace Control view. As far as I understand a trace experiment can be created for each gdb session. If this is correct which one is displayed in the view?
(In reply to comment #71) > (In reply to comment #70) > Marc, regarding the Trace Control view. As far as I understand a trace > experiment can be created for each gdb session. If this is correct which one is > displayed in the view? I've mapped all commands and view content to the active debug context. Therefore, you can run multiple sessions at once and change from one to the other.
(In reply to comment #72) > I've mapped all commands and view content to the active debug context. > Therefore, you can run multiple sessions at once and change from one to the > other. I thought about that. In this case to start or stop tracing you would need to select the right debug context in the Debug view, go to the Trace Control view, and then click at the action button. I would expect at least to have the start/stop actions in the context menu of the Debug view.
(In reply to comment #73) > (In reply to comment #72) > > I've mapped all commands and view content to the active debug context. > > Therefore, you can run multiple sessions at once and change from one to the > > other. > I thought about that. In this case to start or stop tracing you would need to > select the right debug context in the Debug view, go to the Trace Control view, > and then click at the action button. > I would expect at least to have the start/stop actions in the context menu of > the Debug view. Good point. I've been struggling to decide what commands should go where. As you saw, I chose the safe route and kept everything isolated in the new TraceControl view, to avoid over-crowding. Your suggestion is ok I think, especially since I can keep these new context menu commands as part of the Tracepoint action set. I will add them. It is particularly hard to make UI decisions without other people's input, so your feedback is very useful. Thanks.
(In reply to comment #73) > I would expect at least to have the start/stop actions in the context menu of > the Debug view. Does it make sense to have cdt.debug.ui contribute these new menus? They are only supported by DSF-GDB right now, but that is true for all tracepoints. I'm worried that if I add these menu items in DSF-GDB only, then if some other plugin wants to add them, we'll get duplicates, if DSF-GDB is installed. Thoughts?
(In reply to comment #75) > (In reply to comment #73) > > I would expect at least to have the start/stop actions in the context menu of > > the Debug view. > Does it make sense to have cdt.debug.ui contribute these new menus? They are > only supported by DSF-GDB right now, but that is true for all tracepoints. I'm > worried that if I add these menu items in DSF-GDB only, then if some other > plugin wants to add them, we'll get duplicates, if DSF-GDB is installed. > Thoughts? It certainly could be used by the CDI implementation had someone decide to implement it. But same applies to other UI components you are proposing.
(In reply to comment #76) > (In reply to comment #75) > > (In reply to comment #73) > > > I would expect at least to have the start/stop actions in the context menu of > > > the Debug view. > > Does it make sense to have cdt.debug.ui contribute these new menus? They are > > only supported by DSF-GDB right now, but that is true for all tracepoints. I'm > > worried that if I add these menu items in DSF-GDB only, then if some other > > plugin wants to add them, we'll get duplicates, if DSF-GDB is installed. > > Thoughts? > It certainly could be used by the CDI implementation had someone decide to > implement it. But same applies to other UI components you are proposing. Ok, so I'll put the start/stop tracing menus as part of cdt.debug.ui. As for the other UI components, the way I imagined, was that they would tart in DSF-GDB and once stable and accepted by users, we would push them down to cdt.debug.ui. This is what we did for Reverse Debugging.
Anyone has an opinion on where to put the new TraceControl view in the Debug perspective? Currently the plan is that the view would be hidden by default, but if opened it would appear stacked with the Outline view (on the right side of the editor).
Created attachment 156839 [details] Phase two patch (no tracepoint actions) (In reply to comment #68) Here is the patch for phase two but without the Tracepoint Actions. I will build a separate patch for the actions. This current patch covers the following aspects of the design: > 3- A new TraceControl view > 4- Start/Stop/Status of Tracing > 5- Handling of Trace State Variables. > 6- Saving Trace Data Four points I would like to mention: 1- Sadly there is no open source target that currently supports tracing. gdbserver 7.1 will support tracing and I have built this patch using a pre-release. This means that it is not really possible to try out this feature until the release of GDB 7.1 which is scheduled for the end of the February. 2- I've added an Exception to the Status of a failed MI command to report the GDB error message. This should be improved as John suggested. I opened bug 300418 to track this. 3- DSF-GDB now supports that a type of service not be instantiated. For example, when running any GDB older than 7.1, the new TraceControl service will not be instantiated at all. This required some care when shutting down services. 4- When pressing the StartTracing button, the StopTracing button should become enabled. This is not well supported by the platform's DebugCommand framework. The way around this that I found was to re-select the current debug context, to refresh all button enablement. To do this, I actually have the LaunchVMProvider refresh the entire Debug view when getting a Start/Stop tracing event. There is probably room for improvement here, but I fear it would require support from the platform. I will wait a week before committing this patch to see if anyone has comments. Thanks in advance.
(In reply to comment #79) > I will wait a week before committing this patch to see if anyone has comments. Committed. Next step Tracepoint actions (almost ready) and then Visualization of trace data.
BTW, after thinking about it, I renamed the ActionSet from "Tracepoints" to "C/C++ Tracepoints"
(In reply to comment #81) > BTW, after thinking about it, I renamed the ActionSet from "Tracepoints" to > "C/C++ Tracepoints" Nice. That was a point I had jotted down when reviewing your feature description. Unfortunately, I got sidetracked and never finished the review. Soon...
(In reply to comment #82) > (In reply to comment #81) > > BTW, after thinking about it, I renamed the ActionSet from "Tracepoints" to > > "C/C++ Tracepoints" > > Nice. That was a point I had jotted down when reviewing your feature > description. Unfortunately, I got sidetracked and never finished the review. > Soon... Thanks John. It's always good to know others agree on the decisions I'm making.
Marc, I noticed that you changed a few copyright dates from e.g. "2006, 2009" to "2010". As per http://www.eclipse.org/legal/copyrightandlicensenotice.php it should be <first>, <last>. It's just a formal subtlety, but I thought I should mention it.
(In reply to comment #84) > Marc, I noticed that you changed a few copyright dates from e.g. "2006, 2009" > to "2010". As per http://www.eclipse.org/legal/copyrightandlicensenotice.php > it should be <first>, <last>. > It's just a formal subtlety, but I thought I should mention it. Doh! I always wondered about that. Thanks Toni for pointing this out. I didn't know it was policy to keep the first date. I'll try to fix the files I changed.
Created attachment 157622 [details] Copyright fix I've committed this patch with puts back the original date in the copyright. e.g., - * Copyright (c) 2009 QNX Software Systems and others. + * Copyright (c) 2004, 2010 QNX Software Systems and others.
Created attachment 157630 [details] Tracepoint actions for a question This patch supports tracepoints actions but still needs a bit of cleanup. I'm posting it because if someone feels I took the wrong approach I'd rather new early. Here's the potential problem: I'm up to my third try to get tracepoint actions to work. I'll quickly describe the three approaches but first let me say what the fundamental issue is. Tracepoint actions should not be available for breakpoints and breakpoint actions should not be available for tracepoints. For example, you cannot use the 'collect' action for a breakpoint, and it does not make sense to use the 'resume' action for a tracepoint. Implementation choices: 1- Have a complete support of tracepoint actions within the current CDT breakpoint support code. This turned out to cause of lot of duplication of code within the BreakpointActionManager, to keep tracepoint actions and breakpoint actions separated. 2- Re-use the breakpoint action support but implement a separate TracepointActionManager; also have the existing BreakpointActionManager look for ITracepointActions and ignore them. This works well, but limits the features of Tracepoint Actions to what is available for Breakpoint Actions. 3- Duplicate most of the breakpoint action code into separate classes for tracepoints. This leaves the current breakpoint action support unchanged and gives me all the freedom to add more features for tracepoint actions. Admittedly this is not a good long term solution, but I feel it is the best short term solution, since breakpointActions will be migrated to the platform, which will then be the right long-term solution (see bug 295658). Another aspect of this solution is that it keeps all tracepoint actions within DSF-GDB. I think this is safer for now, until we have a proper API in the platform, especially since tracepoint actions are currently very GDB specific. The posted patch uses solution 3. Anyone have strong feelings against going with this type of solution? Thanks
Created attachment 161798 [details] Tracepoint actions Small fixes on the previously posted Tracepoint actions patch. Error handling is not perfect when GDB rejects a tracepoint command and will need to be updated. Committed to HEAD.
(In reply to comment #88) > Created an attachment (id=161798) [details] > Tracepoint actions > > Small fixes on the previously posted Tracepoint actions patch. > Error handling is not perfect when GDB rejects a tracepoint command and will > need to be updated. > > Committed to HEAD. I forgot to mention that this patch is also missing the Global Tracepoint Actions support.
Created attachment 162276 [details] Small fix for TracepointActions preferences The delete button of the TracepointActions preference page was not being called. Committed to HEAD.
Created attachment 164368 [details] Move BreakpointType menu entry down in the popup menu Committed patch to HEAD. It is nicer to have the toggle breakpoint menu entry to be the first one as per: -----Original Message----- From: cdt-dev-bounces@eclipse.org [mailto:cdt-dev-bounces@eclipse.org] On Behalf Of Alena Laskavaia Sent: Thursday, April 08, 2010 4:13 PM To: CDT General developers list. Subject: [cdt-dev] Breakpoint Types? I just updated the code from trunk and there is new context menu Breakpoint Types. The problem is it is the first item where Toggle Breakpoint use to be. It is REALLY annoying because I use to select the menu and click toggle breakpoint and right now I am hitting this menu instead. Can me moved it down?
Created attachment 164739 [details] Phase-three enhanced proposal: visualization The last part of the Tracepoint feature that we need for Helios to have a properly working feature is the visualization of the trace data. I presented this part at EclipseCon and I attached a PDF proposal document with screenshots to this bug. Here is a quick summary. To make it easier to understand, one can consider that each collected trace record is kind of a partial core file: it contains debugging data of a specific point in time. 1- The user will be able to navigate sequentially between the different collected trace records. 2- For the currently-selected trace record, all available data will be shown in the different debug views e.g., variables, registers, memory, debug. 3- whenever the user navigates to a different record, all views will be updated with the newly available data 4- the post-mortem launch will be enhanced to allow to choose between a core file (existing) and a trace file (new). Visualization can be enhanced to allow for better ways to navigate but because Helios is coming fast, I'm restricting myself to the basics. We can add more enhancements after Helios and hopefully once we get user-feedback. I'm cleaning up the patch now and will post before M7.
Created attachment 166134 [details] Phase three implementation: support for trace record visualization Finally, here is the patch for Trace Record visualization for DSF-GDB. It requires a pre-release of GDB 7.2 to test. Although most required support is currently in GDB HEAD, thre is another bug in that branch that prevents using GDB. As soon as that bug is fixed, it will be possible to try out this feature. I will let it sit here for a couple of days if someone wants to review the code. I will commit after that so I can make the feature freeze cut-off.
Created attachment 166237 [details] Phase three implementation (2): support for trace record visualization I found a couple of things to cleanup and I added a details string for the debug view when we are looking at a trace record.
(In reply to comment #94) > Created an attachment (id=166237) [details] > Phase three implementation (2): support for trace record visualization > > I found a couple of things to cleanup and I added a details string for the > debug view when we are looking at a trace record. I've committed this patch to HEAD.
Created attachment 169365 [details] Missing patch to exit visualization mode I realized I missed the patch for the action that allows to stop visualizing trace data. Committed to HEAD.
*** cdt cvs genie on behalf of mkhouzam *** Bug 284286: Trace Record visualization for DSF-GDB [+] ISelectNextTraceRecordHandler.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/internal/commands/ISelectNextTraceRecordHandler.java?root=Tools_Project&revision=1.1&view=markup [+] ISelectPrevTraceRecordHandler.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/internal/commands/ISelectPrevTraceRecordHandler.java?root=Tools_Project&revision=1.1&view=markup [*] LaunchMessages.properties 1.6 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/launching/LaunchMessages.properties?root=Tools_Project&r1=1.5&r2=1.6 [*] FinalLaunchSequence.java 1.10 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/launching/FinalLaunchSequence.java?root=Tools_Project&r1=1.9&r2=1.10 [*] GdbLaunchDelegate.java 1.16 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/launching/GdbLaunchDelegate.java?root=Tools_Project&r1=1.15&r2=1.16 [+] GDBTraceControl_7_2.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/GDBTraceControl_7_2.java?root=Tools_Project&revision=1.1&view=markup [*] GDBProcesses_7_0.java 1.17 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/GDBProcesses_7_0.java?root=Tools_Project&r1=1.16&r2=1.17 [*] IGDBTraceControl.java 1.3 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/IGDBTraceControl.java?root=Tools_Project&r1=1.2&r2=1.3 [-] GDBTraceControl_7_1.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/GDBTraceControl_7_1.java?root=Tools_Project&view=markup [*] GDBRunControl_7_0.java 1.25 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/GDBRunControl_7_0.java?root=Tools_Project&r1=1.24&r2=1.25 [*] GDBRunControl_7_0_NS.java 1.22 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/GDBRunControl_7_0_NS.java?root=Tools_Project&r1=1.21&r2=1.22 [*] GdbDebugServicesFactory.java 1.11 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/GdbDebugServicesFactory.java?root=Tools_Project&r1=1.10&r2=1.11 [+] messages.properties http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/internal/service/command/events/messages.properties?root=Tools_Project&revision=1.1&view=markup [+] MITracepointSelectedEvent.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/internal/service/command/events/MITracepointSelectedEvent.java?root=Tools_Project&revision=1.1&view=markup [+] Messages.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/internal/service/command/events/Messages.java?root=Tools_Project&revision=1.1&view=markup [*] GDBControl_7_0.java 1.17 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/command/GDBControl_7_0.java?root=Tools_Project&r1=1.16&r2=1.17 [+] MITraceRecord.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/output/MITraceRecord.java?root=Tools_Project&revision=1.1&view=markup [+] MITraceFindInfo.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/output/MITraceFindInfo.java?root=Tools_Project&revision=1.1&view=markup [+] MITraceFind.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/commands/MITraceFind.java?root=Tools_Project&revision=1.1&view=markup [*] IGDBLaunchConfigurationConstants.java 1.5 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/IGDBLaunchConfigurationConstants.java?root=Tools_Project&r1=1.4&r2=1.5 [*] MIStack.java 1.12 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/MIStack.java?root=Tools_Project&r1=1.11&r2=1.12 [*] MIRunControl.java 1.26 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/MIRunControl.java?root=Tools_Project&r1=1.25&r2=1.26 [*] MIVariableManager.java 1.9 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/MIVariableManager.java?root=Tools_Project&r1=1.8&r2=1.9 [*] MIExpressions.java 1.14 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/MIExpressions.java?root=Tools_Project&r1=1.13&r2=1.14 [*] CommandFactory.java 1.5 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/CommandFactory.java?root=Tools_Project&r1=1.4&r2=1.5 [*] AbstractMIControl.java 1.14 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/AbstractMIControl.java?root=Tools_Project&r1=1.13&r2=1.14 [*] MANIFEST.MF 1.10 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/META-INF/MANIFEST.MF?root=Tools_Project&r1=1.9&r2=1.10 [*] CMainTab.java 1.9 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/launching/CMainTab.java?root=Tools_Project&r1=1.8&r2=1.9 [+] GdbSelectPrevTraceRecordCommand.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/commands/GdbSelectPrevTraceRecordCommand.java?root=Tools_Project&revision=1.1&view=markup [+] SelectPrevTraceRecordCommandHandler.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/commands/SelectPrevTraceRecordCommandHandler.java?root=Tools_Project&revision=1.1&view=markup [+] GdbSelectNextTraceRecordCommand.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/commands/GdbSelectNextTraceRecordCommand.java?root=Tools_Project&revision=1.1&view=markup [+] SelectNextTraceRecordCommandHandler.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/commands/SelectNextTraceRecordCommandHandler.java?root=Tools_Project&revision=1.1&view=markup [*] plugin.properties 1.14 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/plugin.properties?root=Tools_Project&r1=1.13&r2=1.14 [*] plugin.xml 1.34 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/plugin.xml?root=Tools_Project&r1=1.33&r2=1.34 [*] GdbAdapterFactory.java 1.14 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/GdbAdapterFactory.java?root=Tools_Project&r1=1.13&r2=1.14
*** cdt cvs genie on behalf of mkhouzam *** Bug 284286: Missing icon for StopVisualization [+] stop_visual_trace.gif http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/icons/full/obj16/stop_visual_trace.gif?root=Tools_Project&revision=1.1&view=markup [*] GDBRunControl_7_0.java 1.26 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/GDBRunControl_7_0.java?root=Tools_Project&r1=1.25&r2=1.26 [*] GDBTraceControl_7_2.java 1.2 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/GDBTraceControl_7_2.java?root=Tools_Project&r1=1.1&r2=1.2 [*] IGDBTraceControl.java 1.5 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/IGDBTraceControl.java?root=Tools_Project&r1=1.4&r2=1.5 [*] MIStack.java 1.16 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/MIStack.java?root=Tools_Project&r1=1.15&r2=1.16 [*] MIExpressions.java 1.18 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/MIExpressions.java?root=Tools_Project&r1=1.17&r2=1.18 [+] MITraceFindFrameNumber.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/commands/MITraceFindFrameNumber.java?root=Tools_Project&revision=1.1&view=markup [*] MITraceFind.java 1.2 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/commands/MITraceFind.java?root=Tools_Project&r1=1.1&r2=1.2 [+] MITraceFindNone.java http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/commands/MITraceFindNone.java?root=Tools_Project&revision=1.1&view=markup [*] GDBControl_7_0.java 1.18 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/command/GDBControl_7_0.java?root=Tools_Project&r1=1.17&r2=1.18 [*] CommandFactory.java 1.9 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/CommandFactory.java?root=Tools_Project&r1=1.8&r2=1.9 [*] TracepointsMessages.java 1.2 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/tracepoints/TracepointsMessages.java?root=Tools_Project&r1=1.1&r2=1.2 [*] TracepointsMessages.properties 1.2 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/tracepoints/TracepointsMessages.properties?root=Tools_Project&r1=1.1&r2=1.2 [*] TracepointImageRegistry.java 1.2 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/tracepoints/TracepointImageRegistry.java?root=Tools_Project&r1=1.1&r2=1.2 [*] TraceControlView.java 1.3 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb.ui/src/org/eclipse/cdt/dsf/gdb/internal/ui/tracepoints/TraceControlView.java?root=Tools_Project&r1=1.2&r2=1.3
This bug was assigned and targeted at a now released milestone. As that milestone has now passed, the milestone field has been cleared. If this bug has been fixed, please set the milestone to the version it was fixed in and marked the bug as resolved.
