This is the mail archive of the gdb@sources.redhat.com 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: Torubles with remote stub for m68k


On Tue, Jun 25, 2002 at 11:12:59AM -0400, Peter Barada wrote:
> 
> >> Any help is appreciated!
> >
> >If GDB sets the breakpoint using 'M' (or presumably 'X') commands, then
> >it is the client's responsibility to clear it.  It would be nice to
> >know why that isn't happening.  To observe it in action you can use
> >gdbserver on a GNU/Linux system...
> 
> Huh? That doesn't make sense(at least to me)...
> Why would gdb go to all the trouble of writing the breakpoint and the
> force the stub to remove it?  Does the stub have to remove the
> breakpoint when gdb is reading memory(say for x/10i $pc)?  How can the
> stub manage an unbounded number of breakpoints this way(wouldn't the
> stub be required to allocate memory)?  Where in the documentation is
> this 'symbiosis' mentioned where gdb sets breakpoints and the stub is
> responsible for removing them while stepping?
> 
> Besides, this stub works fine with gdb-4.16 and gdb-4.18, so what's changed?
> 
> I can see that if the 'Z' commands are used to set breakpoints then
> the stub is responsible for managing them, but not the 'M' command...
> 
> Again, any help is appreciated!

Terminology skew.  "the client" is GDB, not the stub; the stub is
essentially a server, like gdbserver is.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer


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