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

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


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

Back to the top