Re: [cdt-dev] Target vs. GDB state & embedded development

[Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx>]

On Thursday 02 October 2008 12:43:03 Øyvind Harboe wrote:
> > This is not the model GDB has -- at any given time gdb can wait both
> > for a target operation to finish *and* accept commands.
> 
> Sorry. I should have specified that I was talking about the remote
> protocol.

Well, CDT knows ideally should not nothing about remote protocol,
and even then...

> 
> Consider what happens if you try to issue a monitor commands while
> GDB has issued a continue packet to the remote JTAG server: it
> can't be serviced.

... remote protocol does allows to send further commands while
continue operation is in progress. I think the patches are in CVS
already. Of course, your stub probably does not implement this mode.

> > I don't think so -- if target is not communicating or powered down,
> > and gdb waits for reply from target, it is messup. And this indicates
> > those states are tightly coupled.
> 
> Actually no. In this case the JTAG server can, sometimes, detect
> the problem and return the step/continue packet.
> 
> At this point the user gets control over the situation and issue
> monitor commands to rectify things.
> 
> > There are two points:
> >
> > 1. Why is target is powered down and needs monitor commands to wake?
> 
> Why is this any of GDB/CDT's business?

Because to build a decent UI, it is necessary to provide accurate
information to UI. 'target remote' is supposed to get you a live
target, and if JTAG debugger fails to do that, it's not problem of
GDB or CDT.

> > 'target remote', or rather the underlying remote protocol, assumes
> > that we connect to already running program. The remote side should
> > either arrange for the target to be powered on, or should return
> > an error.
> 
> The monitor commands will arrange for this to happen.
> 
> Otherwise you need some out of band mechanism to do this that
> will do nothing that can't be done with monitor commands.

Why JTAG debugger cannot perform power-on when accepting connection 
from GDB? Can you give an example of such monitor commands? 

> 
> > 2. If it is desirable to attach to powered down target then remote
> > protocol and GDB should be modified to allow that (I suspect
> > 'target extended-remote' is enough, actually).
> 
> I guess. There are lots of things that GDB should do, in the long
> run, patches gladly accepted, etc.  Many of these things are duely
> reported in the GDB bug database as well.
> 
> Meanwhile, GDB *does* allow connecting to a powered down target
> provided that the JTAG debugger tells a white lie w.r.t. the get
> register packet that is issued during the connection sequence.
> 
> I'll have to take a closer look at the extended remote protocol, but
> last I checked that didn't quite do the trick.
> 
> I think that the main thing that CDT can do is not to *require*
> the target to be alive and well while GDB is in the suspended
> state(i.e. receptive to "monitor" commands).

Can you clarify what exactly CDT requires, and when, and why is this
bad thing?

- Volodya