Bug 187789 - Wrong addresses calculated for local variables (64bit issue, -gstabs or -gstabs+)
Summary: Wrong addresses calculated for local variables (64bit issue, -gstabs or -gsta...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: gdb
Version: 5
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Elena Zannoni
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-04-03 16:50 UTC by Stefan Ring
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-09-11 00:13:51 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Very simple test program in C (83 bytes, text/plain)
2006-04-03 16:50 UTC, Stefan Ring
no flags Details

Description Stefan Ring 2006-04-03 16:50:07 UTC
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
[...]

Comment 1 Stefan Ring 2006-04-03 16:50:07 UTC
Created attachment 127244 [details]
Very simple test program in C

Comment 2 Stefan Ring 2006-04-03 22:12:45 UTC
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.

Comment 3 Stefan Ring 2006-04-06 09:30:56 UTC
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.

Comment 4 Andrew Cagney 2006-09-11 00:13:51 UTC
Stabs is not supported; one reason being 64-bit breakage in the non-existant
spec. Use DWARF 2/3, which is the default.


Note You need to log in before you can comment on or make changes to this bug.