This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
gdb/180: printing expression gives different result to executing equivalent statement
- To: gdb-gnats at sources dot redhat dot com
- Subject: gdb/180: printing expression gives different result to executing equivalent statement
- From: dcoutts at cray dot com
- Date: 24 Jul 2001 16:00:40 -0000
- Reply-To: dcoutts at cray dot com
>Number: 180
>Category: gdb
>Synopsis: printing expression gives different result to executing equivalent statement
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Jul 24 09:08:02 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator: dcoutts@cray.com
>Release: gdb 5.0 (mips-sgi-irix6.5, and others)
>Organization:
>Environment:
native mips-sgi-irix6.5x
gdb build both with system cc, and gcc 2.95.3
>Description:
Printing the value of an expression on the gdb command line
can have a different answer from when the same expression
is evaluated by the machine, even on native targets.
The example I use is long lx = -(1 << 63)
I came across this piece of code when debugging gdb with gdb.
On a 64bit target, this code crops up in get_discrete_bounds
when called with a TYPE_CODE_INT argument:
*lowp = -(1 << (TYPE_LENGTH (type) * TARGET_CHAR_BIT - 1))
As a side issue this code does not have the expected effect
on a 64bit target, it gives the result 0, which is not the
most negative number avaliable in the representation, (which
was the intent of the code, right?)
>How-To-Repeat:
when debugging the attached C program, if we print the value
of the expression we get one answer:
(gdb) p (long) -(1 << 63)
$1 = 0
however, executing the statement and checking the result:
6 lx = -(1 << 63);
(gdb) n
(gdb) p lx
$2 = -2147483648
here lx is defined as long, so I would expect that -(1 << 63)
cast to a long would have the same value as assigning the
same expression to a varialbe of type long.
We get the same behaviour with llx, which is a long long.
On the mips-sgi-irix6.5x target, long is 32bit and long long
is 64bit.
>Fix:
Don't trust the expression evaluation too much.
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="gdb_bug.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="gdb_bug.c"
dm9pZCBtYWluICgpCnsKICBsb25nIGx4OwkgLyogMzJiaXQgb24gbWlwcy1zZ2ktaXJpeDYuNSAq
LwogIGxvbmcgbG9uZyBsbHg7IC8qIDY0Yml0IG9uIG1pcHMtc2dpLWlyaXg2LjUgKi8KCiAgbHgg
PSAtKDEgPDwgNjMpOwogIGxseCA9IC0oMSA8PCA2Myk7Cn0K