Community
Participate
Working Groups
Breakpoint service needs to send notifications when breakpoints are added and removed so that other clients can update their breakpoint tables. Proposal is to add following events: E • Breakpoints • contextAdded • <array of breakpoints> • E • Breakpoints • contextChanged • <array of breakpoints> • E • Breakpoints • contextRemoved • <array of breakpoint IDs> • Breakpoint service needs a way to report its capabilities to clients so they can adjust to different implementations. Proposal is to add C • Breakpoints • getCapabilities • <string: context ID> • R • <token> • <error report> • <object> • When called with a null ("") context ID the global capabilities are returned, otherwise context specific capabilities are returned. A special capability property can be used to indicate that all child contexts have the same capabilities.
Eugene feel free to reassign to Felix if you think it's more appropriate. The proposal seems to make sense for me, though I'm wondering about the following: (1) Given a chain of TCF value-adds, until what level down the food chain should the breakpoint add event be forwarded? Who would eventually be responsible for sending the notification events? note that this is not necessarily the agent, because the breakpoint service itself is likely contributed by a value-add (and probably extended by another value-add). (2) Given that a debug session has been active for some time, and another client who's interested in the breakpoints joins late. How would he find out what breakpoints are active already? - Apparently, he needs to query all active breakpoints. But since we must have a breakpoint query available anyways, why do we need to add so many events? Wouldn't it suffice to have a single event like "breakpoints have changed" and force all interested parties to re-read the entire breakpoints table when getting that event? That would likely also solve the (1) "who's responsible from all value-adds" problem mentioned above.
Proposal to add new properties to breakpoint data to support 1) Watchpoints (on memory or register that can be triggered on combination of read/write/execute/change) 2) Hardware breakpoints 3) Software breakpoints 4) Temporal breakpoints (to break on instruction count, cycle count or time in the relative or absolute time scale) 6) Multicore/multicontext breakpoints, where a breakpoint may be configured to affect multiple runcontrol/process contexts The proposed new properties are: 1) "Type" : <string> - the breakpoint type "Software" - Software breakpoint. "Hardware" -Hardware breakpoint "Auto" - Installed breakpoint type (software/hardware) deferred to agent's discretion. This is the default breakpoint type. The actual type of each breakpoint instance consequently installed is received as a status event 2) "ContextName" : <string> - the context name for which the location expression should be evaluated. The location context could be a memory space name or a register group name. If this property is not provided, the breakpoint will be installed for all runcontrol/process context (these contexts may be limited by the Initiators property) 3) "Expression" : <string> - if preset, defines location of the breakpoint. Location is an expression that evaluates either to a memory address or a register location (with respect to the ContextName property). Alternatively, breakpoint location can be given as File/Line/Column. 4) "AccessMode" : <int> - the access mode that will trigger the breakpoint Access mode can be a bitwise OR of the values below: READ = 0x01 triggered by a read from the breakpoint location WRITE = 0x02 triggered by a write to the breakpoint location EXECUTE = 0x04 triggered by an instruction fetch from the breakpoint location CHANGE = 0x08 triggered by a data change (not an explicit write) at the breakpoint location 5) "Size" : <int> - The number of bytes starting at the location expression to which the AccessMode triggers apply 6) "Pattern" : <int> - a breakpoint can be qualified by a data value or pattern. 7) "Mask" : <int> - a mask which is bitwise ANDed with the data value/pattern. 8) "Time" : <number> - the time value in the execution of the program at which to set the breakpoint 9) "TimeScale" : <string> - the scale for the time value 10) "Relative" Time value in the relative time scale. This is the default value for this property. "Absolute" - Time value in the absolute time scale 11) "TimeUnits" : <string> - the units for the time value "CycleCount" -Time value in cycles. This is the default type. "NanoSeconds" - Time value in nano seconds "InstructionCount" - Time value in instructions 12) "Initiators" : <string> - an array of context identifiers or names for runcontrol/process contexts that can trigger the breakpoint. 13) "StopGroup" : <string> - an array context identifiers or names for runcontrol/process contexts to be stopped when this breakpoint is triggered. 14) "IgnoreCount" : <int> - the number of times this breakpoint is to be ignored before it is triggered. The ignore count must be tested after all other properties are validated. ----------------------------------------------------- Corresponding amendments to breakpoint status definition to provide richer status information: "Instances" : <array of instance status data> "Error" : <string> "File" : <string> "Line" : <int> "Column" : <int> A breakpoint installation can lead to multiple installed instances of the breakpoints. Properties associated with each of those installed instances (or error information in case there was a failure installing an instance) are provided in a list of instance status data objects <array of instance status data> Ø null Ø [ ] Ø [ <Instance status data list> ] <Instance status data list> Ø <Instance status data> Ø <Instance staus data list>, <Instance status data> <Instance status data> Ø <object> Instance status data consists of a list of properties pertaining to each installed instance of the breakpoint. Predefined properties are: "Error" : <string> "BreakpointType" : <string> "LocationContext" : <string> "Address" : <string>
Created attachment 97123 [details] Amendment to the specification for the proposed changes
Sidarth - many thanks for your proposal. This looks very interesting - but it covers a different topic than the original description on this bug. Can you please file a new bug e.g. "[tcf] Breakpoint data structure extensions" for your suggestion. Let's keep this bug focused on the original topic "breakpoint event and capabilities changes". I'm sorry that the original bug summary was misleading. I'm changing it now, previous value was: "[tcf] breakpoint service changes"
Sure. Logged a separate bug: ("[tcf] breakpoint service changes") https://bugs.eclipse.org/bugs/show_bug.cgi?id=228389
Comment on attachment 97123 [details] Amendment to the specification for the proposed changes Attachment is obsolete because its master copy is on bug 228389 now.
(In reply to comment #1) Martin, I'll take a stab at your questions. > (1) Given a chain of TCF value-adds, until what level down the food chain > should the breakpoint add event be forwarded? Who would eventually be > responsible for sending the notification events? note that this is not > necessarily the agent, because the breakpoint service itself is likely > contributed by a value-add (and probably extended by another value-add). To me, a value-add is free to propograte, filter or send out its own event in response to an event from the service that it value-adding. In that sense, the event propogates up the food chain, from the agent up to the host, where each value-add level is free to handle/forward or simply filter it out. This scenario is not specific to the breakpoints service. For example, similar events are provided by the runcontrol, registers and memory service. > (2) Given that a debug session has been active for some time, and another > client who's interested in the breakpoints joins late. How would he find > out what breakpoints are active already? - Apparently, he needs to query > all active breakpoints. > But since we must have a breakpoint query available anyways, why do we > need to add so many events? Wouldn't it suffice to have a single event > like "breakpoints have changed" and force all interested parties to > re-read the entire breakpoints table when getting that event? That would > likely also solve the (1) "who's responsible from all value-adds" problem > mentioned above. As you are suggesting, we could certainly have a client pull for updates instead of pushing updated data to it. But Felix's proposal is more consistent with the other services. Runcontrol, registers, memory services have a "getChildren". But the events for those service push updated data to the client instead of simply sending it a "contexts have changed event" and having clients pull the udpated data. Whichever way we choose, imo we ought to be consistent.
(In reply to comment #7) Thanks for your thoughts on events ... yes, these are good points and I agree. > Whichever way we choose, imo we ought to be consistent. I don't agree here since I think it depends on the use-case. For some services there might be tons of data that few listeners care about. Such a scenario cries for a "pull" mechanism. In other cases, lots of listeners might want to hear about frequently changing small amounts of data. Such cases cry for a "push" mechanism. Doing the right thing depending on the usage scenario is more important than consistency, in my opinion.
(In reply to comment #8) > (In reply to comment #7) > Doing the right thing depending on the usage scenario is more important than > consistency, in my opinion. I see your point. Barring a subscription mechanism where a client can register level of interest (which seems like an overkill at this point), I agree that the model will depend on the usage scenario and will be subjective.
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > Doing the right thing depending on the usage scenario is more important than > > consistency, in my opinion. > I see your point. > Barring a subscription mechanism where a client can register level of interest > (which seems like an overkill at this point), I agree that the model will > depend on the usage scenario and will be subjective. I agree that a subscription mechanism is overkill. IMO the design of services should be done in a way that allows optimization of traffic while at the same time allowing agents to be as simple as possible. One such optimization that has been discussed is to allow the client to optimize away events when no client has expresses interest in the information. For example take the RunControl service on a UNIX system with processes and threads. An "intelligent" agent is free to optimize away any contextAdded/contextRemoved events until some client has done getChildren. Likewise, contextChanged events don't have to be sent for any context where no client asked for the information in the first place. The agent would need some mechanism to periodically force the client to re-express interest in the information. A really intelligent agent could even keep track of which channels have expressed interest in information and then send the events to only those channels. None of this has been prototyped, so at this point this is just ideas.
I have commited changes to docs, agent & host-side code, and tests to support new events and command - as it was proposed.
Moving bugs to new home for IP log.
Bulk update: Marking all bugs from the TM era (before June 2011) target 0.3
