Re: [tcf-dev] reduced getState function

["Gherzan, Mircea" <mircea.gherzan@xxxxxxxxx>]

Hi Eugene,

Along these lines, please re-review/reconsider the native part of the getMinState story: https://git.eclipse.org/r/c/tcf/org.eclipse.tcf.agent/+/172121 

Thanks, 
- Mircea

From: tcf-dev <tcf-dev-bounces@xxxxxxxxxxx> On Behalf Of Eugene Tarassov
Sent: Tuesday, May 25, 2021 7:04 PM
To: TCF Development <tcf-dev@xxxxxxxxxxx>
Subject: Re: [tcf-dev] reduced getState function

Hi David,

Yes, if your target can retrieve all needed context state info without reading PC, it can be used to make GUI updates somewhat faster.

However, the GUI patch (https://git.eclipse.org/r/c/tcf/org.eclipse.tcf/+/175151) is no good.
The context state is used at about 50 places throughout the code.
Some of them don’t really need PC and could use getMinState.
Others will break without PC. I tried the patch – it looks bad, causes problems.

I’m going to commit changes that will use getMinState when it is available and PC not needed, but fall back to getState in other cases.
I verified that in certain cases it can update GUI using getMinState only.

Regards,
Eugene

From: tcf-dev <mailto:tcf-dev-bounces@xxxxxxxxxxx> On Behalf Of Wilson, David
Sent: Tuesday, May 25, 2021 4:04 AM
To: TCF Development <mailto:tcf-dev@xxxxxxxxxxx>
Subject: [tcf-dev] reduced getState function

CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.

Hi Eugene, 

Sorry to ask again, I was wondering if you have had a chance to look over my email from 19/5/2021? The email is as follows:

--- original message ---
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.
---end of original message---


This is a completely blocking issue for us, and one that we believe other TCF developers and users will also encounter. 

Any help/comments would be greatly appreciated.

Kind Regards

David Wilson
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, http://www.intel.de
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva   
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928