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

["Øyvind Harboe" <oyvind.harboe@xxxxxxxxx>]

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.

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

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

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

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.



-- 
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer