bug-gdb
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Cannot see source code of shared library


From: Pierre Sarrazin
Subject: Cannot see source code of shared library
Date: Tue, 19 Dec 2000 12:05:51 -0500
User-agent: Mutt/1.2i

I am trying to put a breakpoint in some function of a dlopened
shared library.  Before the dlopen() call, this function is not
known to gdb, which is normal.  But even after the library has
been loaded by dlopen(), gdb still does not know the function:


(gdb) l CDicoGlobal.c:1
No source file named CDicoGlobal.c.
(gdb) l CDicoGlobal::IDicoGlobal
Can't find member of namespace, class, struct, or union named 
"CDicoGlobal::IDicoGlobal"
Hint: try 'CDicoGlobal::IDicoGlobal<TAB> or 'CDicoGlobal::IDicoGlobal<ESC-?>
(Note leading single quote.)
#
# Here, I type "l 'CDicoGlobal::IDicoGlobal" and then TAB:
#
(gdb) l 'CDicoGlobal::IDicoGlobal(CIdentifiant const *)' 
No line number known for 'CDicoGlobal::IDicoGlobal(CIdentifiant const *)'.


However, this seems to be dependent on the executable that calls
dlopen().  When I try it with a very small executable, everything
works.  The problem described above happens when I use the real
executable, which is much bigger.

Does GDB have problems handling large executables?  This situation
makes it very difficult for me to send a reduced example of the
problem.

I find it strange that GDB was able to complete the method name
when I hit the TAB key, while it wasn't able to display the source.

I am using a developement copy of GDB obtained from the CVS server
today, December 19th, 2000.  The executables and the shared library
were compiled with g++ 2.95.2 with the "-g" switch on a Pentium-based
RedHat 6.2 system.

I seem to remember that "g++ -gdwarf-2" might make a difference in
such situations, but that the resulting executables would take way
too much disk space.

-- 
Pierre Sarrazin <sarrazip at machinasapiens dot com>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]