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 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


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