Target vs. GDB state & embedded development

[Øyvind Harboe]

One thing that confuses CDT is that the target and GDB state are only
very loosly coupled.

E.g. when I connect to a target, that target could be in any state:

- running
- halted
- other... eg. powered down

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.

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.

So what I'm driving at here is that CDT should not think of the
target as running or not running, but rather as either waiting
for a continue or step packet to terminate.

The register/target information returned when GDB is not
waiting for continue/step to complete, may be a blunt
lie as the target may in fact be powered down...

--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

[Daniel Jacobowitz-2]

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.

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

If your setup causes GDB to return "blunt lies" to CDT, then
CDT shouldn't work around that problem.

--
Daniel Jacobowitz
CodeSourcery
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

[Øyvind Harboe]

On Wed, Oct 1, 2008 at 8:13 PM, Daniel Jacobowitz <drow@...> 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
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

[Pawel Piech]

I'm not familiar with the monitor commands or how they can affect the
system state, but I can say that the IDE debugger integration relies
heavily on knowing the state of the target.  If the user is able to
modify this state "behind GDB &CDT's back", then the only option for the
IDE to deal with this situation is to try to discover the target state
with just about every operation.  Unfortunately this strategy leads to
very poor performance.

So my point is that we can do our best in supporting the CLI interface,
but ultimately there's only so much we can do without proper support
from the backend itself.  That said, if the perfmance trade off doesn't
scare you off, you should also be able to extend DSF-GDB and add the
state discovery logic on top.  I say "should" because it's difficult to
know whether the architecture will fully support what you need to do
without trying...

Cheers,
Pawel

Øyvind Harboe wrote:

> One thing that confuses CDT is that the target and GDB state are only
> very loosly coupled.
>
> E.g. when I connect to a target, that target could be in any state:
>
> - running
> - halted
> - other... eg. powered down
>
> 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.
>
> 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.
>
> So what I'm driving at here is that CDT should not think of the
> target as running or not running, but rather as either waiting
> for a continue or step packet to terminate.
>
> The register/target information returned when GDB is not
> waiting for continue/step to complete, may be a blunt
> lie as the target may in fact be powered down...
>
>  

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

[Vladimir Prus-3]

On Wednesday 01 October 2008 22:23:36 Øyvind Harboe wrote:

> On Wed, Oct 1, 2008 at 8:13 PM, Daniel Jacobowitz <drow@...> 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
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

[Øyvind Harboe]

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

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
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
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

[Vladimir Prus-3]

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

 


_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

[Øyvind Harboe]

On Thu, Oct 2, 2008 at 10:59 AM, Vladimir Prus
<vladimir@...> 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
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev