Re: [tcf-dev] Evaluating expression : Best practise ?

[Eugene Tarassov <eugene.tarassov@xxxxxxxxxx>]

Hi Xavier,

Symbols getContext is supposed to return "Offset" in simple cases: when field location can be described by byte offset (not a bit-field, etc.), and the offset is static (we want symbols info to be cacheable). Complex cases can only be represented by a location expression. Location expression is static, so it is cacheable, while result of its evaluation is not. In theory, a client can get location expression using Symbols getLocationInfo command, and evaluate it itself. But it is much easier to use Expressions service to evaluate location expression. I suggest to use "Offset" when available, otherwise use Expressions service.

Expressions getChildren could return IDs of sub-expressions for fields if argument represents an expression for a structure. This might be a bit more convenient for a client than doing Expressions create "CTX" null "(${structId}).${fieldId}", but it is not implemented yet. So, for now, you have to use Symbols getChildren, then do "Expressions create" to covert symbol ID of a field to expression ID.

Regards,
Eugene


-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Xavier Pouyollon
Sent: Tuesday, April 07, 2015 6:00 AM
To: TCF Development
Subject: [tcf-dev] Evaluating expression : Best practise ?

Hi Eugene,

We have a command-line tool that implements the GdbType / GdbValue like GDB with the Python interface.

One design rule was to avoid using Expression Create to get the various sub-fields like the IDE is doing (see below) for performance reason and to make it more language agnostic.

The idea was to:
Expression create "structure"
Expression evaluate : We get the "dump" of the structure + some types info.
Loop within the Types and send Symbols getContext / getChildren.
Retrieve the field value through the "Offset" property (which is the "index" in the "dump") and display it according to the type.

I'm not sure it's a good idea, especially since the Expression service
does:
- Indirect Evaluation (for AT_data_location). In such case, the "dump"
will be incomplete.
- Only expression service is able to return complex infos like
  "Pieces":[{"BitSize":1,"Address":1745100492}]
  (Which is the case for the bit_field sample here)

Please see the attached zip file.
We have some comments in bit_fields.txt.
The questions are there : "would expect to have following properties :
"Pieces":[{"BitSize":15,"BitOffs":1,"Address":1745100492}]"

Are our expectations too high for Symbols getContext  ?
I think it could work on simple structure when "Offset" is returned by getContext but won't in case of complex replies (using Pieces) or won't work if it requieres indirection (like AT_data_location).

In other words, should our tool mimic the IDE like this:
Expression Create "structure"
Issue some Symbols getContext / getChildren and for each field:
     Expression create "CTX" null (${structId}).${fieldId})"
     Expression evaluate to the field value
     Symbol getContext to get the field type

Moreover, we are not fully clear about when to use:
Expressions getChildren (seem to deal with stacktrace to retrieve arguments)
    vs
Symbols getChildren (what we believe we must use to dump structure)

Can you please comment on this and provide guidance ?

Many thanks,
Xavier.


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.