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

[Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx>]

On Wednesday 01 October 2008 22:23:36 Øyvind Harboe wrote:
> On Wed, Oct 1, 2008 at 8:13 PM, Daniel Jacobowitz <drow@xxxxxxxxx> wrote:
> > On Wed, Oct 01, 2008 at 07:03:51PM +0200, Øyvind Harboe wrote:
> >> When CDT believes that the target is running(i.e. when CDT is not
> >> waiting for GDB to complete the continue/step packet), it is
> >> possible to issue "monitor" commands via the GDB console.
> >
> > Do you have a wrong negative in that sentence?  It doesn't make sense.
> 
> CDT has a concept of the target either being suspended or running. This is
> not the right model.
> 
> CDT should consider that GDB is either waiting for a step/continue
> packet to complete or that GDB is accepting commands.

This is not the model GDB has -- at any given time gdb can wait both
for a target operation to finish *and* accept commands.

> Whether the target is running/halted/powered down/not communicating
> via JTAG is completely orthogonal to the state of GDB.

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.

> 
> >
> >> These monitor commands can reset, step, continue, run, halt,
> >> modify registers, etc. all behind GDB & CDT's back. Upon the
> >> next step/continue command to GDB, GDB will pick up all the
> >> changes again.
> >
> > It sounds to me like you're using a hardware debugger to do some
> > imitation of GDB's async and non-stop modes, without telling GDB
> > about it.  The DSF folks are working on async and non-stop mode in
> > cooperation with the GDB developers, which is clearly the way to
> > go.
> 
> The above seems to assume that the hardware debugger is in control
> of the target. That is not case.
> 
> The target can be powered down, reset, disconnected from the
> JTAG debugger without the JTAG debugger being able to do
> anything about it.
> 
> Issuing multiple GDB "monitor" commands or otherwise interacting
> the target can restore the target to a halted/running state upon
> which normal debugging can be resumed.

You seem to say that it's possible to do something with target
bypassing GDB/JTAG link, so that GDB does not notice. Then, I
don't see what problem we have.

 
> > If your setup causes GDB to return "blunt lies" to CDT, then
> > CDT shouldn't work around that problem.
> 
> The problem is that CDT shouldn't make assumptions about the
> target, it should just present the values that GDB tells it.

Well, one of the values GDB tells if whether any given thread
is running, or stopped.

> One of the lies is that the target is powered down upon connecting
> to it using "target remote". The "target remote" involes a get register
> packet where the hardware debugger has no choice but to return
> success and bogus values so as to let the "Target remote" succeed
> after which the .gdbinit script can issue "monitor" commands
> to restore order to the world.

There are two points:

1. Why is target is powered down and needs monitor commands to wake?
'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.

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).

- Volodya