Bugzilla – Full Text Bug Listing
| Summary: | For full system debug we need to specify which contexts breakpoints and configuration should apply to | ||
|---|---|---|---|
| Product: | [Tools] TCF | Reporter: | Anders Conradi <anders.conradi> |
| Component: | Core | Assignee: | Project Inbox <tcf.core-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | Eugene Tarassov <eugene> |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | cdtdoug, christophe.augier, felix.burton |
| Version: | unspecified | ||
| Target Milestone: | 1.1 | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
Thanks for putting this proposal together, it seems to be a good balance between capability and complexity, and it seems to be extensible without breaking backwards compatibility, so overall it seems very good. I have some questions that I hope you can help with: - What is the semantic for relative queries, i.e. that does not start with "/"? Is the query "<part1>/<part2>" identical to "/**/<part1>/<part2>"? - For "property", which service or set of services are used to retrive the property? I don't think we require that properties from different services must have globally unique names, so don't we need some way to specify which service and which object, e.g. RunControl service has two object 1) context properties and 2) status, a property comes from? Thanks, Felix > Thanks for putting this proposal together, it seems to be a good balance > between capability and complexity, and it seems to be extensible without > breaking backwards compatibility, so overall it seems very good. I have some > questions that I hope you can help with: > > - What is the semantic for relative queries, i.e. that does not start with "/"? > Is the query "<part1>/<part2>" identical to "/**/<part1>/<part2>"? Yes, that's the intention. > > - For "property", which service or set of services are used to retrive the > property? I don't think we require that properties from different services > must have globally unique names, so don't we need some way to specify which > service and which object, e.g. RunControl service has two object 1) context > properties and 2) status, a property comes from? I didn't think of that. My suggestion would be to ignore things outside the context properties. Then you have to figure out how to handle the same property name being used in more than one service. I would like context queries to be manually writable, so I'd prefer a syntax that does not a burden to input. I can see a couple of options: - Let a context match a query if any of its values for a property matches the value in the query. - Require that the user to specify the full name of the property, for example <service>.<property>. You could combine the options and allow unqualified properties in a query to match any property and allow the user to constrain the property to a particular service and object if he wants. I have committed an initial implementation of context queries. Please, have a look. I think the service ContextQuery does fulfill this enhancement request. Could you please close the bug? Thanks. (In reply to comment #4) > I think the service ContextQuery does fulfill this enhancement request. > Could you please close the bug? Closed. Thanks. |
Build Identifier: We want to be able to specify subsets of a system as the target of commands and configuration by the user. Let us call these commands and application of configuration as setup to make it easier to talk about. There are several different kinds of setup: you want to set breakpoints, you want to tell the debugger where it can find source code for the programs it debugs, you want to tell the debugger where it can find debug and symbol information for the binaries it debugs. In some cases you even want to tell the debugger where various binaries (libraries, executables, plug-ins, etc) are loaded in a process's address space. In the simple case the same setup is valid for the entire system being debugged. In other case they are only valid for a single already running program. We still need to support such use cases, but here I want to talk about more complex usecases where different parts of the debugged system needs different setup. Examples of this is when you debug a multi-machine system running different versions of the same program on different operating systems. Often there are no processes running the program you want to debug when you need to do the setup. You may need to set a breakpoint in the startup code of a program that exits before you can catch it with the debugger. You may need to set up symbol information before the program has started executing. You also want to avoid having to do this more than once. If you develop the program you want to debug using an IDE like Eclipse a lot of the non-breakpoint setup are part of the configuration for the project which builds the program. This case needs to be supported. However you cannot rely on this. There are cases when you just want to debug a program without having to set up a project in an IDE. This is especially true for developers coming from a command line background and are most comfortable building their programs from the command line. This case also needs to be supported. = Overview This proposal suggest that we use a query based system to specify subsets of context a setup should be applied to. The queries specifies context properties and what values they need to have to match. In addition a query can filter based on a contexts ancestors in the context hierarchy. The set of properties you can use in queries are not specified. You can also look at the context hierarchy and the ancestors of contexts. This allows the user to restrict the matching contexts to contexts on a particular machine or in a particular operating system. Each context will provide its own set of properties which can be used in queries. The default property will be the name of the context, which in the special case of processes running a particular program should be the name of the name of the program. Since the set of properties is not fixed and can be different for different contexts it becomes harder to do a GUI for it. However, the simple cases -- matching all contexts, and a particular program name -- are still quite simple. This proposal applies to the Breakpoints, Pathmap and Memorymap services in TCF. Each of these services will use the same syntax and semantics for the queries. This will be described first. Then the integration with each service will be described. = Syntax and Semantics query = [ "/" ], { part, "/" }, part ; part = string | "*" | "**" | properties ; properties = property, { ",", property } ; property = string, "=", value ; value = string | number | boolean ; string = quoted string | symbol ; quoted string = '"', {any-character - ('"' | '\') | ('\', ('"' | '\'))}, '"' ; symbol = letter, { letter | digit } ; number = digit, { digit } ; boolean = "true" | "false" ; letter = ? A-Z, a-z or _ ? ; digit = ? 0-9 ? ; any-character = ? any character ? ; To give a feel for the syntax, here are some examples, and what a user might mean when providing such a query: httpd Matches all contexts named "httpd". pid=4711 Matches any context with a property pid, which has the value 4711. /server/** Matches all contexts which are decendants of the top level context named "server". "Linux 2.6.14"/Kernel/* Matches all kernel processes in operating systems named "Linux 2.6.14". pid=4711/* All threads in processes with the pid 4711. /server/**/HasState=true All threads which are decendants of the context "server". The contexts are assumed to be placed in a tree. Each context has zero or one parent. If it has zero parents it is a child of the root of the tree. A query consists of a sequence of parts separated by "/". This sequence specifies a path through the context tree. A context matches the query if the last part of the query matches the properties of the context and the parent of the context matches the query excluding the last part. The properties of a context matches a part if each property specified in the part matches the property of the same name in the context or if the name of the context matches the string specified in the part. There are also two wild cards. The part "*" matches any context. The part "**" matches any sequence of contexts. If the query starts with a "/" the first part of the query must match a child of the root of the context tree. = Context Properties The properties of a context are the same properties as presented by the Processes service and other similar services which presents the tree of contexts on the target. = Breakpoints Each breakpoint has an optional ContextQuery property which specifies a context query. This is used as an additional breakpoint condition. The context which hit the location of the breakpoint must match the query or be in a breakpoint group which matches the query for the breakpoint to trigger. = Pathmap Each entry has an optional ContextQuery property and an entry is only considered in the translation if the context you translate is in a context symbols group which matches the query. If the ContextQuery property is not specified or the context matches the query the entry is considered as before. = Memorymap Each memory region specified in the memory map has an optional ContextQuery property. The memory region is only part of the memory map for contexts in a context symbols group which matches the query. If a memory region does not specify a ContextQuery it is part of the memory map as normal. Reproducible: Always