Re: [PATCH] Add 'reverse' capability query to remote protocol (qSupported).

[Pedro Alves <pedro@codesourcery.com>]

On Monday 07 September 2009 23:19:09, Michael Snyder wrote:
> Michael Snyder wrote:
> > Pedro Alves wrote:
> >> What about the i18n comments?
> > 
> > Oof, sorry, forgot.  You just mean the two error msgs, right?
> > See revised diff.

Yep.  Thanks.

> >> What about the vCont (the one about not sending vcont
> >> if requesting a reverse resume) comments?
> > 
> > Are you sure?  I guess, like you, I hoped it would eventually
> > be added.  Works fine as it is, it probes and fails, but if
> > you want it, ok...  added below.

That's because your target doesn't support vCont, otherwise, the target
will run forward instead of backwards.  Granted, the
target_can_support_reverse check at a higher layer will prevent getting
here if neither bc or bs are supported, but, there may be targets that
end up supporting both (forward) vCont and bs+bc.

> > I have one final question to raise.
> > 
> > You may notice (though nobody has commented), that I made the
> > two new supported-probed-packets (bs and bc) default to "enabled".
> > 
> > This sort of defeats the purpose (if the purpose is that we can
> > decide whether to run a testsuite on a remote target) -- but I
> > was just reluctant to default them to "disabled", because it
> > would mean that anybody with a deployed target that doesn't yet
> > support the new "qSupported" probe would have to make his users
> > enable them by hand.
> > 
> > (why I cc:ed Jakob and Greg.)
> > 
> > So now that I've mentioned it, what do you think?
> > Enabled, or disabled by default?
> 

Oh, I totally missed that.  When would they be set to
disabled without user intervention then?  E.g., what happens
against current gdbserver?  Does it still misbehave when trying
to reverse step?

Given there's an easy workaround (set remote foo-packet on),
I vote disabled by default.

-- 
Pedro Alves