This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> jtc@RedBackNetworks.com (J.T. Conklin) writes: > > I finished my breakpoint extensions prototype, and discovered that GDB > > inserts all enabled breakpoints when program execution is resumed, and > > removes them when it regains control. > > Yes, this is a "feature". It's pretty well wired into GDB. It might > be possible to make insert_breakpoints() and remove_breakpoints() do > some sort of caching-like thing, but I'm not sure that all target > memory reads know about substituting original code, so you might get > punished when you're doing disassembly or prologue analysis. You're right, target memory reads don't know about substituting the original code. I got around that problem by having my stub restore memory before control is returned to GDB and to (re-)insert break- points just before program execution resumes. I haven't investigated, but it's conceivable that some ROM monitors do the same thing (for much the same reasons --- simplifying internal disassembly). If GDB was extended to avoid inserting and removing breakpoints, it could only be used on targets that manage breakpoints in this manner. --jtc -- J.T. Conklin RedBack Networks