This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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?

Thanks,
Hui


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]