This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
msymbols being truncated to 32 bits.
- To: gdb at sources dot redhat dot com
- Subject: msymbols being truncated to 32 bits.
- From: Michael Snyder <msnyder at cygnus dot com>
- Date: Fri, 16 Feb 2001 15:16:55 -0800
- CC: kevinb at redhat dot com, keiths at redhat dot com, jimb at redhat dot com
- Organization: Red Hat
OK, this is twice now that I've run into this. I thought at first
that it was because I'm dealing with a harvard architecture, but
now I think it's just because there are some old 32-bit assumptions
still lying around in GDB, and I'm dealing with a 64-bit target.
Here's the deal. I say "print top" in nodebug.exp, and I get
the address truncated to 32 bits. After poking around a bit,
I find that the expression parser has actually parsed this
as a long (and then cast it to a function pointer.
Looking at parse.c, I find a function "write_exp_msymbol",
which puts an msymbol onto the expression stream as an OP_LONG.
The comments for OP_LONG in expression.h say that it's followed
by a type, and then a long constant. So there's my 32-bit
truncation.
Interestingly, right after OP_LONG in expression.h comes
OP_DOUBLE, and in 1996 Stu Grossman changed the argument
of OP_DOUBLE from a "double" to a "doublest". He did not
simultaneously change the argument of OP_LONG to a longest.
Nor is there an OP_LONGEST.
So I'm wondering whether we should:
1) change the argument of OP_LONG to longest, or
2) add a new OP_LONGEST operator.
Anybody have any thoughts? JimB -- you're our expression
parser expert. ;-)
Michael