[RFC] Autoload-breakpoints new version [0/9]

Stan Shebs stanshebs@earthlink.net
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 <stanshebs@earthlink.net> wrote:
>> On 8/7/12 12:06 AM, Hui Zhu wrote:
>>> Hi,
>>>
>>> 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?
>>
>> Stan
>> stan@codesourcery.com
>>
> 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.

Stan
stan@codesourcery.com



More information about the Gdb-patches mailing list