Red Hat Bugzilla – Bug 187789
Wrong addresses calculated for local variables (64bit issue, -gstabs or -gstabs+)
Last modified: 2007-11-30 17:11:29 EST
Description of problem:
When trying to look at local variables (or function parameters), gdb gives me
"Cannot access memory at address 0x<garbage><yyyyyyyy>", where <yyyyyyyy> would
be the correct address.
Version-Release number of selected component (if applicable):
GNU gdb Red Hat Linux (188.8.131.52-1.122rh)
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db
Always when showing stack traces for programs built with -gstabs+ or -gstabs.
Steps to Reproduce:
1. Build the attached test program with "gcc -gstabs+ test.c"
2. gdb ./a.out
3. br a
Breakpoint 1, a (x=Cannot access memory at address 0x8000ffd85118
) at test.c:3
Breakpoint 1, a (x=<some address close to 0xffd85118>
) at test.c:3
The production case which bugs me looks like this (the value 0x00000001 in the
upper 32 bits):
#0 vtex_breakpoint () at VTXMLMessages/CLS_XMLMessages.cpp:268
#1 0x000000000066366b in VTException::VTException (this=Cannot access memory at
) at VTXMLMessages/CLS_XMLMessages.cpp:445
#2 0x0000000000415869 in VTE_TP<AnsiString> (xc=Cannot access memory at address
) at VTCOM/../VTXMLMessages/CLS_XMLMessages.h:118
#3 0x000000000053478c in network_error () at VTCOM/CLS_VTCOMUnix.cpp:34
#4 0x0000000000536bdf in VTCOMUnixSocketAdaptor::next (this=Cannot access
memory at address 0x1432038b8
) at VTCOM/CLS_VTCOMUnix.cpp:121
#5 0x00000000005348fc in VTCOMUnixSocketAdaptor::ReceiveString (this=Cannot
access memory at address 0x143203948
) at VTCOM/CLS_VTCOMUnix.cpp:170
#6 0x000000000052fb5f in VTCOMMarshaller::ReadFromSocket (this=Cannot access
memory at address 0x1432039e8
) at VTCOM/CLS_VTCOM.cpp:218
#7 0x0000000000532dc9 in VTCOM::GetNextRequest (s=Cannot access memory at
) at VTCOM/CLS_VTCOMServer.cpp:136
#8 0x0000000000532ea2 in VTCOM::ServerRequestLoop (s=Cannot access memory at
) at VTCOM/CLS_VTCOMServer.cpp:157
Created attachment 127244 [details]
Very simple test program in C
Apparently, SYMBOL_VALUE (var) contains a signed 32 bit value in
read_var_value() that has not been correctly expanded to long. I haven't been
able to find out where it originates from, however.
Maybe it's a gcc problem and doesn't have anything to do with gdb at all because
it seems to work with gcc 3.4.
Stabs is not supported; one reason being 64-bit breakage in the non-existant
spec. Use DWARF 2/3, which is the default.