| [tcf-dev] reduced getState function |
|
Hi All – We are having an issue at TCF protocol level relating to performance on Systems which have many Contexts.
The issue relates to the getState command being called on all contexts, which in turn, triggers a read on the program counter (pc) register. On systems with a large number of contexts (especially over real hardware with JTAG), this has a massive performance penalty.
Now, we have seen several types of target where we can infer the state (i.e. has a breakpoint been hit, is it suspended etc) WITHOUT reading the PC. We would still like to show the “State” to the user, and thus have come
up with a getMinState solution (detailed
https://git.eclipse.org/r/c/tcf/org.eclipse.tcf.agent/+/172121) and GUI patch (https://git.eclipse.org/r/c/tcf/org.eclipse.tcf/+/175151) Eugene Tarassov very kindly provided me with another potential solution to this, by not intercepting contexts. This would not require any code change. Unfortunately, is not an acceptable solution for us, as it does not
allow us to provide the user with all the information we “know” – i.e. have the contexts been suspended or not. Eugene suggested “suspended, intercepted, but not active",
which I can’t figure out how to trigger from the tcf agent (where we need this behaviour to come from) – simply setting this as “not active” from the client also seems cumbersome and unintuitive for a end user. Hence it seems the current approaches will not
work to fix this issue. Any help with our particular problem would be greatly appreciated. Kind Regards David Wilson Intel Deutschland GmbH |