Expression Evaluation

The following areas need work:

Arithmetic Logic Unit

At present GDB uses the host's floating-point and integer units to implement the target's arithmetic operations. There are a number of limitations with this approach, however, the most significant is that GDB does conversions to/from a largest type when manipulating the arithmetic value. This is what leads to strange truncated behaviour such as 1.1 becoming 1.0999....

One proven solution is to provide:

alternatively, a native centric solution may be to:

In addition, Keith? is looking at extending the expression evaluator to correctly handle overloaded operators

Location Slicing and Splicing

At present GDB's value code limits the location of modifiable (lval) target objects (variables, parameters, ...) to exclusively a register or contigious memory. If the debug information describes an LVAL split between registers and/or dis-contigious memory then gdb converts the LVAL into an RVAL; removing the ability to modify the original target value. This is what leads to GDB refusing to modify very large integers (value in multiple registers) or structures (split between memory and registers).

One proven solution is to describe the LOCATION of the VALUE's raw bytes as a list of PIECES, that is:

A request to transfer one or more of a VALUE's bytes (either a read or write) is broken down and converted into requests to transfer bytes to/from one or more of the VALUE's LOCATION's PIECEs.

In addition to removing the limitation preventing GDB from handling values with more complex locations, this mechanism facilitates the addition of operators such as slicing and splicing - they can be implemented by slicing and/or splicing value locations.

Name Resolution

Sami is extending GDB's internal representation of static block scope so that it can implement C++ name resolution rules. For instance, representing a "using" clause, letting GDB correctly handle such source code.


Keith is extending GDB's lexer/parser so that it no longer requires quotation marks around symbols. For instance, removing the requirement that a qualified C++ name be quoted for tab completion to work.

In addition, the parser can be extended to support:

Value Display

Tom is extending GDB's printer to better display C++ values.


Here you will find an analysis of GDB's expression evaulator, and areas that it can be improved.






Floating-point precision

print 1.1

print 1.1
$1 - 1.0999999999999999

GDB manipulates floating-point values by casting them to a DOUBLEST; this can introduce precision artefacts
Instead the debugger should evaluate floating-point expressions using the language's floating-point rules

128-bit Integers

print ((int128_t)1) << 64

That operation is not available on integers of more than 8 bytes.

Integer expression evaluation is limited to LONGEST - typically 64 bits


Static members

Dynamic members

Static tab completion

Dynamic tab completion

Quoting for symbol table name

Function Calls

Simple C function



Static C++ function


Final C++ method

Virtual C++ method


Overloaded Operator - explicit


Overloaded Operator - implicit



Display the expresion's value

Display the expression's type

Read Only

Display the expression's location

Display the expression's parse tree

Slice Operators


Array indexing, given:
static int a[2] = { 1, 2 };

print 1[a] + a[1]
$1 = 2

(gdb) print 1[a] + a[1]
cannot subscript something of type `int'

It's a problem with the expression evaluator

Array slice, given:
static int a[2] = { 1, 2 };

print a[0:1]
{ 1, 2 }


Requires a richer description of locations

Record slice, given:
struct { int a, b; } s[2] = { { 1, 2}, { 3, 4} };

print s.a
{ 1, 3 }


Requires a richer description of locations

None: Expressions (last edited 2008-11-05 16:25:01 by ip-209-167-232-100-yyz)

All content (C) 2008 Free Software Foundation. For terms of use, redistribution, and modification, please see the WikiLicense page.