Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Target vs. GDB state & embedded development

> 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

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.

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

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

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

Øyvind Harboe
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer

Free eCos workshop in Oslo October 21!

Back to the top