Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tcf-dev] Handling of storage size in Expressions service 
Makes sense.

Thanks,

Vincent

Eugene Tarassov wrote on 21/04/2016 19:37:

Hi Vincent,

Compiler optimizations can promote a variable to a bigger type, for example, store a 32-bit integer as 64-bit number in a register. In such case, a debugger can do one of:

1. Let user see and edit actual 64-bit value;
2. Get user input on how to convert the value between actual and declared type: LSB or MSB, zero or sign extended;
3. Choose appropriate conversion by an educated guess.

TCF debugger does #1, because: if the application has a bug, which causes invalid value of the variable (e.g. 0x10000000000), #1 would reveal the bug instantly, while #2 and #3 would hide the bug, which defeats the purpose of debugger.

Regards,
Eugene



-----Original Message-----
From: tcf-dev-bounces@xxxxxxxxxxx [mailto:tcf-dev-bounces@xxxxxxxxxxx] On Behalf Of Vincent Hue
Sent: Thursday, April 21, 2016 6:36 AM
To: tcf-dev@xxxxxxxxxxx
Subject: [tcf-dev] Handling of storage size in Expressions service

Hi all,

this question is related to a bug I filed recently (#489742).

I am using the expression service from a python script to
assign a value to a variable. The variable is an int (4 bytes).
So, I use "Expressions create" (which confirms "Size":4),
and then "Expressions assign" with a 4 bytes value encoded (e.g. "AAAACg==").

The issue is that my variable is stored in a 64 bits register,
and because of the endianess, the wrong part of the register is updated.

Although I can propose a fix for this, I wondered if it was the right approach...

Indeed, I checked the behavior of the TCF code in Eclipse/CDT, and
it works fine, only because the java client does things differently.

The eclipse.tcf.debug.ui will first "evaluate" the variable.
This returns a 64-bit buffer (e.g "AAAAAAAAAAo=") bigger than the variable.
It will use the size of the returned buffer for the new value encoding,
then pass it to "Expressions assign".

So, my question is : Shall the expression service cope with such size mismatch
(it does seem to handle the reverse case : big value into small register)
or shall the client support the burden of checking value size and perform
and padding/over-sizing  ?

Any feedback is welcome

Regards,

Vincent
_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tcf-dev


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.

_______________________________________________
tcf-dev mailing list
tcf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tcf-dev

Back to the top