This is the mail archive of the
mailing list for the GDB project.
Re: [patch/rfc] Disable [eE] packets by default
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Michael Snyder <msnyder at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: 26 Feb 2002 12:29:47 -0500
- Subject: Re: [patch/rfc] Disable [eE] packets by default
- References: <3C79867F.firstname.lastname@example.org> <3C798723.4D4B@redhat.com>
> [...] I think this is the right thing to do. [...]
OK. Can you or Andrew explain the reference to "threading code" in
the patch comments?
> > + /* Disable by default. The ``e'' packet has nasty interactions with
> > + the threading code - it relies on global state. */
> > + remote_protocol_E.detect = CMD_AUTO_BOOLEAN_FALSE;
> > + update_packet_config (&remote_protocol_E);
> I would like to start discussing the right way to implement this.
> For one thing, the current implementation has remote.c snatching
> control away from infrun, and doing something completely
> different from what infrun asked it to do.
Right - it's interpreting the step=1 argument to remote_resume not
just as "stepi" but as "step if you can, stepi if you can't".
> I'd like to have the decision about whether to use step-over-range
> made in infrun, not in the target layer.
Yup. One less-pessimistic approach would be to clear step_range_end
and step_range_start in proceed(), if the breakpoint_here_p()
condition is true. This would mean that targets would have to do
stepi loops when stepping off of a breakpoint, but otherwise could use