[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Target vs. GDB state & embedded development
|
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...
