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 (6.3.0.0-1.122rh) This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/libthread_db.so.1". How reproducible: 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 4. r Actual results: Breakpoint 1, a (x=Cannot access memory at address 0x8000ffd85118 ) at test.c:3 Expected results: Breakpoint 1, a (x=<some address close to 0xffd85118> ) at test.c:3 Additional info: 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 address 0x143202f28 ) at VTXMLMessages/CLS_XMLMessages.cpp:445 #2 0x0000000000415869 in VTE_TP<AnsiString> (xc=Cannot access memory at address 0x14320335c ) 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 address 0x143203ad8 ) at VTCOM/CLS_VTCOMServer.cpp:136 #8 0x0000000000532ea2 in VTCOM::ServerRequestLoop (s=Cannot access memory at address 0x143203b50 ) 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.