Re: [cdt-debug-dev] Displaying values of custom data types

["Mikhail Khodjaiants" <mikhailk@xxxxxxx>]

Matthias,

Can you provide some examples to make it easier to see the problems?
Speaking in general, I am getting more and more convinced that we should get 
the formatted values from the backend instead of using generic formatters.
As for presentation, we probably need to provide an extension or replacement 
mechanism for debugger implementors.

Mikhail Khodjaiants
----- Original Message ----- 
From: "Matthias Spycher" <matthias@xxxxxxxxxx>
To: <cdt-debug-dev@xxxxxxxxxxx>
Sent: Tuesday, January 31, 2006 12:53 PM
Subject: [cdt-debug-dev] Displaying values of custom data types


> We have extended to the gdb/mi layer in our product to treat certain 
> struct types as well-known fundamental types whose values can be displayed 
> directly as numbers in the variables/expressions views. For example, we 
> have a C++ library of fixed point types and big integer types. There 
> appears to be a limitation in the current cdt.debug.core API when it comes 
> to value formatting. Some of our struct types also implement ICDICharType 
> so they can be converted to string values, but this doesn't allow for the 
> formatting of numbers in hex, decimal, etc. The following code in 
> CDebugModelPresentation checks for character and floating point types, but 
> doesn't care to check integer types before eliminating arrays and structs 
> (which is why our struct types implement ICDICharType).
>
>            try {
>                String valueString = value.getValueString();
>                if ( valueString != null ) {
>                    valueString = valueString.trim();
>                    if ( type != null && type.isCharacter() ) {
>                        if ( valueString.length() == 0 )
>                            valueString = "."; //$NON-NLS-1$
>                        label.append( valueString );
>                    }
>                    else if ( type != null && type.isFloatingPointType() ) 
> {
>                        Number floatingPointValue = 
> CDebugUtils.getFloatingPointValue( (ICValue)value );
>                        if ( CDebugUtils.isNaN( floatingPointValue ) )
>                            valueString = "NAN"; //$NON-NLS-1$
>                        if ( CDebugUtils.isPositiveInfinity( 
> floatingPointValue ) )
>                            valueString = CDebugUIMessages.getString( 
> "CDTDebugModelPresentation.23" ); //$NON-NLS-1$
>                        if ( CDebugUtils.isNegativeInfinity( 
> floatingPointValue ) )
>                            valueString = CDebugUIMessages.getString( 
> "CDTDebugModelPresentation.24" ); //$NON-NLS-1$
>                        label.append( valueString );
>                    }
>                    else if ( type == null || (!type.isArray() && 
> !type.isStructure()) ) {
>                        if ( valueString.length() > 0 ) {
>                            label.append( valueString );
>                        }
>                    }
>                }
>            }
>            catch( DebugException e1 ) {
>            }
>
>
> Furthermore, the number types are bounded in range when the values are 
> retrieved in CValue. For example:
>
>    private String getIntValueString( ICDIIntValue value ) throws 
> CDIException {
>        CVariableFormat format = getParentVariable().getFormat();
>        if ( CVariableFormat.NATURAL.equals( format ) || 
> CVariableFormat.DECIMAL.equals( format ) ) {
>            return (isUnsigned()) ? Long.toString( value.longValue() ) : 
> Integer.toString( value.intValue() );
>        }
>        else if ( CVariableFormat.HEXADECIMAL.equals( format ) ) {
>            StringBuffer sb = new StringBuffer( "0x" ); //$NON-NLS-1$
>            String stringValue = (isUnsigned()) ? Long.toHexString( 
> value.longValue() ) : Integer.toHexString( value.intValue() );
>            sb.append( (stringValue.length() > 8) ? 
> stringValue.substring( stringValue.length() - 8 ) : stringValue );
>            return sb.toString();
>        }
>        return null;
>    }
>
> We could add new interfaces that would allow for the conversion of stucts 
> into strings or numbers in the debug presentation model, or we could work 
> with the existing interfaces and eliminate the assumption that signed 
> integers are bounded 32-bit quantities, etc. I would prefer the former 
> solution, but I am interested in hearing what the cdt debug experts think.
>
> Matthias
>
>
> _______________________________________________
> cdt-debug-dev mailing list
> cdt-debug-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev