public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* problem debugging on solaris x86 with gdb-5.3
@ 2003-04-21 15:44 Tony Wetmore
  0 siblings, 0 replies; only message in thread
From: Tony Wetmore @ 2003-04-21 15:44 UTC (permalink / raw)
  To: gdb

[-- Attachment #1: Type: text/plain, Size: 2174 bytes --]

Hi,

I am running into a bit of a problem debugging an application on Solaris
x86 using GDB version 5.3.  I do not appear to be able to set
breakpoints in shared library code within my application.
Unfortunately, if I build a very simple test application, this problem
does not occur.

The heart of the problem appears to be that GDB cannot correctly
determine the address of class member functions in my application.  For
example, I have a class called "NominalData" whose code is part of a
shared library "libproject.so".  When I ask GDB for the address of that
method, the address output by GDB is not valid.

For example, here is part of the output from "info shared" showing the
library in question...

   (gdb) info shared
   From        To          Syms Read   Shared Object Library
   0xdf904b00  0xdfa2904e  Yes
/home/username/work/project/lib/libproject.so

Now here is the output from the "info address" command, as well as my
attempt to put a breakpoint on a method within that class:

   (gdb) info address NominalData::deserializeXML
   Symbol "NominalData::deserializeXML(SerialStr&)" is a function at
address 0x4225df.

   (gdb) b NominalData::deserializeXML
   Cannot access memory at address 0x4225df

Shouldn't the address of that method be in the range of addresses
allocated to the shared library in which the method resides?  I suspect
that address 0x4225df is in a region of memory that is "off limits" to
me, which is why the breakpoint cannot be set there.

The method is a normal C++ class method, not inline or anything.  It is
implemented in a file called "NominalData.C" which is linked into the
"libproject.so" shared library.

Has anyone ever seen this strange behavior?  Is there anything I can try
to help isolate the problem?

In case it has other usefulness, I have attached the debugger session
script where I started up GDB, stopped at main, dumped out the shared
libraries loaded then tried to set the breakpoint.

I am using GCC version 3.2.1 to build this application, along with the
native Solaris x86 assembler and linker.

Thanks!

---
Tony Wetmore
Solipsys Corporation
mailto:tony.wetmore@solipsys.com
http://www.solipsys.com
 
 

[-- Attachment #2: session.gdb-5.3 --]
[-- Type: application/octet-stream, Size: 2898 bytes --]

Script started on Mon Apr 21 11:03:32 2003
[username@hostname:~/rmt] $ gdb-5.3 `which program`
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-pc-solaris2.8"...
(gdb) b main
Breakpoint 1 at 0x80532f4: file program.C, line 202.
(gdb) run
Starting program: /home/username/work/project/bin/program 
[New LWP 1]
[New LWP 2]
[New LWP 3]
[New LWP 4]

Breakpoint 1, main () at program.C:202
202	  Timer::startScenarioClock( Timer::getCurrentTime( Time::Real ) );
(gdb) info shared
From        To          Syms Read   Shared Object Library
0xdf904b00  0xdfa2904e  Yes         /home/username/work/project/lib/libproject.so
0xdf6f43a4  0xdf727dfa  Yes         /home/username/work/project/lib/libproject2.so
0xde4b0e90  0xde613552  Yes         /home/username/work/subsystemA/lib/libsubsystemA.so
0xdf5c4e08  0xdf5fecbe  Yes         /home/otheruser/work/subsystemB/lib/libsubsystemB.so
0xdf54d2ac  0xdf5525ba  Yes         /home/username/work/project/lib/libproject3.so
0xdd97536c  0xdd9befd6  Yes         /home/username/work/subsystemC/lib/libsubsystemC.so
0xdf3afc50  0xdf48ff9e  Yes         /home/otheruser/work/subsystemD/lib/libsubsystemD.so
0xdf2e7e00  0xdf2ec72e  Yes         /home/otheruser/work/subsystemE/lib/libsubsystemE.so
0xdc532900  0xdc6d75fa  Yes         /home/username/work/subsystemF/lib/libsubsystemF.so
0xddecf2c0  0xddf494ca  Yes         /home/username/work/subsystemG/lib/libsubsystemG.so
0xdde13c9c  0xdde141bc  Yes         /usr/lib/libpthread.so.1
0xddde26e4  0xddde5172  Yes         /usr/lib/librt.so.1
0xdd797ee8  0xdd7985c2  Yes         /usr/local/gcc-3.2.1/lib/libstdc++.so.5
0xdddc190c  0xdddc8e38  Yes         /usr/lib/libm.so.1
0xddda1020  0xddda52de  Yes         /usr/local/gcc-3.2.1/lib/libgcc_s.so.1
0xdd6e8908  0xdd746d8d  Yes         /usr/lib/libc.so.1
0xdd63ed84  0xdd695713  Yes         /usr/lib/libnsl.so.1
0xddd737ac  0xddd791c8  Yes         /usr/lib/libsocket.so.1
0xdd5ea540  0xdd601dfc  Yes         /usr/lib/libcurses.so.1
0xdd5c1d04  0xdd5c62f6  Yes         /usr/lib/libaio.so.1
0xdfbb0734  0xdfbb0775  Yes         /usr/lib/libdl.so.1
0xdd580ba4  0xdd5825c8  Yes         /usr/lib/libmp.so.2
0xdbfc74c4  0xdbfd85d1  Yes         /usr/lib/libthread.so.1
(gdb) info address NominalData::deserializeXML
Symbol "NominalData::deserializeXML(SerialStr&)" is a function at address 0x4225df.
(gdb) b NominalData::deserializeXML
Cannot access memory at address 0x4225df
(gdb) kill
Kill the program being debugged? (y or n) y
(gdb)
[username@hostname:~/rmt] $ exit

script done on Mon Apr 21 11:05:13 2003

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2003-04-21 15:44 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-21 15:44 problem debugging on solaris x86 with gdb-5.3 Tony Wetmore

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).