Community
Participate
Working Groups
Created attachment 97212 [details] Amendment to the breakpoint data structures 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 97246 [details] Updated the Breakpoint Services spec Fixed a couple of typos/errors in the previous attachment.
For the most part the proposal looks very good. I think we need to be very crisp in how breakpoint properties relate to each other, so I would like to propose that we express their relationships in terms of expressions and pseudo code. From the highest point of view, I see breakpoints are three things: 1. Location 2. Condition 3. Action This can be expressed as: IF Location && Condition THEN Action It is a little bit arbitrary what is expressed in the Location and what is expressed as part of the Condition, but the way I see it, the Location is something that is fairly constant and the Condition is something that has to be re-evaluated fairly frequently. To be more precise, the criteria to re-evaluate the Location are 1. Context creation and deletion 2. Symbol load and unload, e.g. shared library The criterion to re-evaluate the Condition is that the Location is hit. Given this, we should be able to categorize all breakpoint properties into one of the above three buckets. Location: Enabled, Type, ContextIds, ContextNames, Expression, AccessMode, Size, File, Line, Column, Pattern, Mask, Time, TimeScale, TimeUnits, Condition: Condition, IgnoreCount Action: StopGroup The buckets will of course grow as we add additional properties. This allows us to create pseudo code for what the breakpoint service should do. Example: Location: IF NOT bp.Enabled RETURN IF DEFINED ContextIds THEN // Use context-id list provided by client ELSE IF DEFINED ContextNames || DEFINED ExecutablePaths || DEFINED OtherContextSelector THEN // Build list of context ids FOR-EACH ctx IN ALL-ATTACHED-CONTEXTS DO IF DEFINED ContextNames && NOT ctx.id IN ContextNames CONTINUE IF DEFINED ExecutablePaths && NOT ctx.id IN ExecutablePaths CONTINUE IF DEFINED OtherContextSelector && NOT ctx.id IN OtherContextSelector CONTINUE ContextIds += ctx; DONE ELSE ContextIds = ALL-ATTACHED-CONTEXTS ENDIF FOR-EACH ctx IN ContextIds DO IF DEFINED File || DEFINED Line || DEFINED Column || DEFINED Expression THEN IF DEFINED Expression THEN loc = EVALUATE Expression ELSE loc = SOURCE_LOCATION(File, Line, Column) ENDIF SET_BP(loc, Type, AccessMode, Size, Pattern, Mask) ELSE IF DEFINED Time THEN SET_TEMPORAL_BP(Time, Type, TimeScale, TimeUnits) ELSE // Unknown breakpoint type ENDIF DONE Condition: IF DEFINED Condition && NOT EVALUATE Condition RETURN FALSE IF DEFINED IgnoreCount THEN IgnoreCount— IF IgnoreCount != 0 RETURN FALSE IgnoreCount = bp.IgnoreCount ENDIF RETURN TRUE Thoughts? Some minor changes: - Change Expression -> Location - Add “Temporary” property to indicate that breakpoint is removed first time it is hit - Change Initiators -> ContextIds - Mention that “Time” can be negative when relative
I like the highlevel spec very much, just two questions: 1.) What about watchpoints -- would these fall into your buckets as well, with location=="*" for "any" and the condition evaluated (in hardware typically) on every memory access? 2.) What about hardware breakpoints -- I don't see the property "isSoftware" vs "isHardware" fall into any of your buckets... or would it be the expression bucket? I think it's important to be able and retrieve capabilities of hardware breakpoints on a particular architecture, how would such capabilities be expressed? Should we open a separate bug for that?
(In reply to comment #3) > I like the highlevel spec very much, just two questions: > 1.) What about watchpoints -- would these fall into your buckets as well, > with location=="*" for "any" and the condition evaluated (in hardware > typically) on every memory access? Watchpoint are supported by the "AccessMode" property. > 2.) What about hardware breakpoints -- I don't see the property "isSoftware" > vs "isHardware" fall into any of your buckets... or would it be the > expression bucket? Hardware vs. software breakpoints/watchpoints are controlled by the "Type" property. > I think it's important to be able and retrieve capabilities of hardware > breakpoints on a particular architecture, how would such capabilities be > expressed? Should we open a separate bug for that? https://bugs.eclipse.org/bugs/show_bug.cgi?id=227874 proposes adding a getCapabilities command. This command should be able to describe HW breakpoint capabilities. Having said this, I don't think it is very easy to describe this in a generic way, so we still need some proposal for how the metadata should look like.
Created attachment 98392 [details] Updated TCF breakpoint service spec
(In reply to comment #2) Hi Felix, Thanks for the excellent feedback. I am attaching an updated spec based on your feedback and the discussions we've since had. I have omitted the pseudo-code, but have tried to convey the meaning in natural language. Thanks, Sidharth
Comment on attachment 97246 [details] Updated the Breakpoint Services spec A new revision attached.
Created attachment 98686 [details] Updated Breakpoint service spec Minor updates based on discussions
Contributed changes after adding some clearifications and reformatting for consistency.
Sidharth - I just noticed that you never explicitly mentioned that you license your spec contribution under the EPL, and actually have the right doing so. Could you please add a comment here on bugzilla, based on the template at http://www.eclipse.org/dsdp/tm/development/committer_howto.php#external_contrib
Legal Message: I, Sidharth Kodikal, declare that I developed attached code from scratch, without referencing any 3rd party materials except material licensed under the EPL. {I am authorized by my employer to make this contribution under the EPL.}
Moving bugs to new home for IP log.
Bulk update: Marking all bugs from the TM era (before June 2011) target 0.3
