[RFC] Autoload-breakpoints new version [0/9]
Mon Oct 15 13:46:00 GMT 2012
On 8/11/12 9:18 AM, Hui Zhu wrote:
> On Sat, Aug 11, 2012 at 6:35 AM, Stan Shebs <firstname.lastname@example.org> wrote:
>> On 8/7/12 12:06 AM, Hui Zhu wrote:
>>> This is the new version for autoload-breakpoints.
>> The first thing I'd like to suggest is to change the terminology.
>> "Autoloading" is really a behavior of GDB, not a property of the
>> breakpoints, which might be better said to be "predefined", or
>> "target-defined", or "externally-supplied" or some such. As we've discussed
>> before, this is conceptually similar to GDB handling tracepoints when
>> disconnected tracing is in effect; in that case,
>> I didn't call those tracepoints anything special, I called the process of
>> acquiring them "uploading".
>> The analogy with tracepoints isn't perfect, because one of the assumptions
>> is that other tools may be modifying these breakpoints behind our backs,
>> perhaps via nothing more complicated than the big red reset button. :-) (And
>> thus the need for asynchronous notification.) So unlike tracepoints, we
>> likely want to remember which ones originated from the target, rather than
>> from GDB.
>> I think "target-defined breakpoint" (and watchpoint, etc) best captures the
>> concept, and avoids any unwanted connotations. Does anybody have a
>> different term that they would like better?
> I like this name, it is very clear. :)
> And I have a question is current patches the target-defined
> breakpoints just can be set by both gdb part and the remote target
> part. What about make GDB cannot change them in command line?
I think ultimately that would have to be up to the target, and maybe
with a future patch the target could say whether the breakpoint could be
modified by GDB. For instance, if the target just defined some
convenience breakpoints, then the user ought to be able to disable or
delete them if they are unwanted, or conflict with another breakpoint.
On the other hand, if the uploaded breakpoint corresponds to a
compiled-in trap, or some kind of hardware hack that can't be disabled
except via soldering iron :-) , then in that case the user should be
informed of what changes are not allowed.
But although a nice feature to have, this isn't necessary for the
current patch set, and so let's not worry about it right now.
More information about the Gdb-patches