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

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

On Thu, Oct 2, 2008 at 10:59 AM, Vladimir Prus
<vladimir@xxxxxxxxxxxxxxxx> wrote:
> 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...

It has to know about the remote protocol to the extent that the
remote protocol imposes limitations on CDT.

>> 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 recall hearing something about this.

However, it will be *years* until this makes it into all the hardware
debuggers out there so CDT will have to take into account hardware
debuggers that don't support this.

Even with this support, it might make things *more* complicated for
GDB, since it would imply that it was possible to e.g. examine memory
while the target is running and stuff like that...

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

The jtag debugger didn't "fail" to do this. The target will be powered up/down
as part of it's normal behaviour. It's not a PC, it's an embedded device.

Specific excamples? Battery powered applications can put targets into
deep sleep where they don't even respond to JTAG communication.
I'm sure there are more. Pressing a physical button on the device revies it
into a running mode. The example is invented and you may argue that
it is contrived, but the point is that the assumption that the target is
live when connecting to it with a debugger is a bad one for embedded
development.

There is nothing wrong, there is nothing that "failed".

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

Because it shouldn't. When to power on and off the target is none of
the JTAG debuggers business. This is in the hands of the developer
and the target/application itself.

> Can you give an example of such monitor commands?

gdb init example:

# power cycle target
monitor power off
monitor power on
monitor sleep 1000
monitor reset init

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

I do owe you that, don't I :-)

I don't have specific examples available *right now*. My next projectlet
with CDT is to figure out why (if this is still the case) that CDT CVS HEAD
and GDB CVS HEAD didn't work together when attaching to a
powered down target.


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

Free eCos workshop in Oslo October 21!
http://www.zylin.com/workshop.html