Can't step into shared library function
d...@snakebrook.com
I'm pretty sure linux as well.
I can't step into a function contained within my shared library. I have
broken out a simple example where the .so containes just a single
function: foo() and the main.c program contains main() which calls
foo() and exits. The program works as foo() prints out a message. I
can't, however, use gdb to step into the foo() form main(). Yes, the
source for foo.c is compiled with -g. Here's the comlete output from
make:
andromeda: /home/dao/tmp > make
cc -g -c main.c
cc -g -c foo.c
cc -shared -o libfoo.so foo.o
cc -o main main.o -L. -lfoo
The versions of the OS, gcc and gdb are
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
GNU gdb 6.2
Linux andromeda 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386
GNU/Linux
This is red hat 9.
Attempting to step into foo() from main() results in essentially the
safe thing as 'next'. I am typing 'step' to make sure I am not hitting
some alias.
I'm just baffled by this.
Any help is appreciated.
Thanks, Jack
Alvin Beach
Try adding -fPIC when linking libfoo.so. Like:
cc -shared *-fPIC* -o libfoo.so foo.o
Not sure if this will help.
I've recently been having problems with breaking inside of shared libraries.
I even would static link the library and I still couldn't break into it.
Sometimes kdbg would just crash and sometimes it would hang. I think ddd
worked though but would have a hard time displaying some variables and
classes.
Alvin
David E. Konerding DSD staff
Try linking with -g (both for the -shared and the final link). Might not make a difference, but...
Andrei Voropaev
I'm doing it all the time and it works perfectly. To make your example
work I had to add -fpic flag to compilation of foo.c (AMD64 does not
create shared lib without this flag) and also set LD_LIBRARY_PATH=. to
make sure that the library is found. My tools are similar to yours: gcc
3.3.5 and gdb 6.3. Though they are self-compiled (no rpm)
--
Minds, like parachutes, function best when open
d...@snakebrook.com
all link lines, to no efect.
andromeda: /home/dao/tmp > m
cc -g -c main.c
cc -g -c foo.c
cc -fPIC -g -shared -o libfoo.so foo.o
cc -fPIC -g -o main main.o -L. -lfoo
GDB just won't allow me to step into the function contained in
libfoo.so. This is unbelievable. This works on Solaris. This is not
working on Linux.
Here's main.c:
main(int argc, char **argv)
{
foo();
}
Here's foo.c:
void
foo()
{
printf("Exiting: foo()\n");
}
Here's a dump of the debug session:
(gdb) break main
Breakpoint 1 at 0x8048444: file main.c, line 5.
(gdb) run
Starting program: /home/dao/tmp/main
Error while mapping shared library sections:
libfoo.so: Success.
Breakpoint 1, main (argc=1, argv=0xbfffe7f4) at main.c:5
5 foo();
(gdb) step
Exiting: foo() <=== should have stepped into foo(), but didn't.
6 }
(gdb) quit
What could I possibly be doing wrong here?
Here's something interesting though:
(gdb) break foo
Cannot access memory at address 0x6e4
I can't set a breakpoing on foo() either ????
Anyone know what's going on? The program works when run either
standalone on within GDB. Just can't step into the shared library.
Any info appreciated.
Thanks, Dan
Alvin Beach
I don't know the answer, but here's somethings to try:
1. Set the breakpoint in main() where you call foo(). Then step into foo()
and see if that works.
2. Try a frontend like ddd or kdbg and see if you can set a break point. You
will need open the source file for foo.c and set the breakpoint before
running.
3. Try compiling both main and libfoo with "-g3 -O0" this will put full
debug info and absolutely no optimasations.
Hope these help, keep us posted :)
Alvin
--
Alvin Beach
Paul Pluzhnikov
> I added -fPIC to all link lines, to no efect.
Naturally: '-fPIC' is a *compile*-time flag, not a link-time flag.
> cc -g -c foo.c
Make that 'cc -g -fPIC -c foo.c', and try again.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
Last2Know
You probably need to put the directory containing foo
in your current LD_LIBRARY_PATH, or else use the -rpath
option when compiling. Most people are having trouble
reproducing your problem because their LD_LIBRARY_PATH
already starts with :
> Thanks, Jack
Abhi
objdump on that so shows? anything interesting?
d...@snakebrook.com
Abhi wrote:
> seems your .so is not properly built. What does a nm or elfdump or
> objdump on that so shows? anything interesting?
Well, I have posted the source for main.c and foo.c, I've shown all of
the switches that are used when building the simplest of shared
libraries, and the simplest of executables. Perhaps you can tell me how
to build it properly such that gdb can step into the function in the
shared library?
nm doesn't tell anything interesting.
Dan
d...@snakebrook.com
I habe been setting a breakpoint on main, and then 'step'ing into
foo(), but gdb will not allow me to step into foo.
Dan
d...@snakebrook.com
Correct me if I am wrong, but I don't believe that anoone on this
thread said that they were successful in stepping into foo().
WHat makes you think this is a LD_LIBRARY_PATH problem? Don;t you think
that if it was a LD_)LIBRARY_PATH problem that gdb would barf when
attempting to load the main executable? It would. If it was an
LD_LIBRARY_PATH problem, the application would not run at all.
Read my first post.
Dan
d...@snakebrook.com
Yea, I've added the -fPIC flags to the compile line, and the link line.
gdb will not allow me, under any circumstances, to step into foo();
Have you tried this? I've posted the source and all flags I'm using to
build the application. I'd love to find someone who can build this
simple test on Linux and be able to step into foo();
I don't believe it can happen.
This works on Solaris flawlessly. and I do mean FLAWLESSLY!
Dan
d...@snakebrook.com
Here's some news on this problem. I have 4 linux systems here. I have
uncovered exactly 1 system where said problem can be built and gdb will
allow me to step into foo() when I build the software as specifiec in
previous posts.
3 of the systems and it's doesn't work.
System A (does not work):
---------------------------------
OS: 2.4.20-24.7
gcc: 2.96
gdb: 5.2-2
System B (doesn't work)
--------------------------------
OS: 2.4.21
gcc: 2.96
gdb: 5.2-2
System C (doesn't work):
--------------------------------
OS: 2.4.20-8
gcc: 3.2.2
gdb: 6.2
System D (it does work here):
-------------------------------------
OS: 2.4.20-8smp
gcc: 3.2.2
gdb: (5.3post-0.20021129.18rh)
This is screwed up. Why would it work one just 1 of these systems? I
have no idea. This should work everywhere. This is so simple.
Dan
Alvin Beach
> I habe been setting a breakpoint on main, and then 'step'ing into
> foo(), but gdb will not allow me to step into foo.
I've tried your test files and these are my results. I don't use gdb
directly though. I used the kdbg frontend.
Compiling main.c and foo.c as described I was not able to step into foo()
from main() nor was able to stop at the breakpoint at the printf().
However, I did have some success when I statically linked libfoo.a (or
foo.o) to main. I was able stop at the breakpoint at the printf(). However,
I still was not able to step into foo() from main.
I compiled libfoo.a using the commands:
$ ar crv libfoo.a foo.o
$ ranlib libfoo.a
Then linked like:
$ cc -g3 -O0 -o main main.o libfoo.a
So, try linking to your library statically and see if that make any
difference. Try breaking at foo and see if you can step into it. If not,
set a breakpoint inside of foo and see if gdb will stop there.
I'm at a loss as to the reason for this. Perhaps my results may shed light
on this?
Hope this helps,
Alvin
Paul Pluzhnikov
> This is screwed up.
It is ...
> Why would it work one just 1 of these systems? I
> have no idea. This should work everywhere.
On *all* of my systems it works just fine:
1. salmon: SuSE 7.3
gcc version 2.95.3 20010315 (SuSE)
gdb-5.0-148
also works when built by gcc-3.4.0
2. buffalo: RH-6.2
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
gdb-4.18-11
also works when compiled with: gcc-2.95.3, gcc-3.2, gcc-3.4.3
and with gdb-5.0, 5.2, 6.0, 6.3
3. troll -- RedHat 9.0
gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
gdb-5.3post-0.20021129.18
4. steer -- Mandrake 10
gcc (GCC) 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)
GNU gdb 6.0-2mdk (Mandrake Linux)
I don't know how you've managed to screw up all of your systems :-(
Here is a trace from the last system for your enjoyment:
$ sh -x build.sh
+ cc -g -c main.c
+ cc -g -c foo.c
+ cc -fPIC -g -shared -o libfoo.so foo.o
+ cc -fPIC -g -o main main.o ./libfoo.so
$ gdb --version
GNU gdb 6.0-2mdk (Mandrake Linux)
Copyright 2003 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 "i586-mandrake-linux-gnu".
$ cc --version
cc (GCC) 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gdb -q ./main
Using host libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) b main
Breakpoint 1 at 0x804847c: file main.c, line 3.
(gdb) r
Breakpoint 1, main (argc=1, argv=0xbffff4a4) at main.c:3
3 foo();
(gdb) step
foo () at foo.c:4
4 printf("Exiting: foo()\n");
(gdb) n
Exiting: foo()
5 }
(gdb) n
main (argc=1, argv=0xbffff4a4) at main.c:4
4 }
(gdb) n
0x4004295d in __libc_start_main () from /lib/tls/libc.so.6
(gdb) n
Single stepping until exit from function __libc_start_main,
which has no line number information.
Program exited with code 017.
(gdb) q
Alvin Beach
I have finally had success stepping into foo()! I used a "Data Display
Debugger" (ddd) this time. I was able to break at the call to foo() and
then step into it. I'm not sure what, but kdbg must be doing something
weird with gdb.
I also tried Paul Pluzhnikov's gdb commands and it seems to set into foo
just fine (with or without the -q switch).
Alvin
Andrei Voropaev
I've told you already that it works perfectly fine for me. But without
LD_LIBRARY_PATH the executable won't run at all because on my system
loader does not search for libraries in the current directory by
default. It checks only "standart" /lib64, /usr/lib64, etc.
All the tools that I'm using are compiled from sources downloaded from
appropriate project pages. So these are "normal" tools. If yours do
not work, then you either do something wrong, or don't have "normal"
tool. (BTW, did you try to use 'directory' command in gdb to specify
where the sources for your library are?)
Jim Cownie
% setenv LD_BIND_NOW 1
(or the bash equivalent).
That ensures that all dynamic linking has been performed when the
dynamic libraries are loaded, rather than on demand the first time
each function in a library is called.
It's entirely possible that your problem is caused by the debugger
being unable to track the step into through the whole of the dynamic
linker...
--
-- Jim
--
James Cownie <jco...@etnus.com>
Etnus, LLC. +44 117 9071438
http://www.etnus.com
Jens.T...@physik.fu-berlin.de
> Correct me if I am wrong, but I don't believe that anoone on this
> thread said that they were successful in stepping into foo().
Just another data point: it works (also) for me with gdb with no
problem at all. I can step into foo() or set a breakpoint in the
library. And that kind of things have been working for me for
years now. I tried on a more or less unmodified SuSE 9.0 system.
> WHat makes you think this is a LD_LIBRARY_PATH problem? Don;t you think
> that if it was a LD_)LIBRARY_PATH problem that gdb would barf when
> attempting to load the main executable? It would. If it was an
> LD_LIBRARY_PATH problem, the application would not run at all.
It's definitely not a LD_LIBRARY_PATH problem when the program works
when simply called from the command line. The way I compiled it (after
adding the necessary header file, a declaration of foo() and a return
statement in main()) with
gcc -g -c -o main.o main.c
gcc -g -fpic -shared -c -o foo.o foo.c
gcc -g -fpic -shared -o libfoo.so foo.o
gcc -g -o main main.o -L. -lfoo
On my system I have to set LD_LIBRARY_PATH to the current directory
but I have to do that already to be able to run the program on its
own, i.e. without the debugger. But even that isn't necessary, of
course, if I do the final linking with
gcc -g -o main main.o ./libfoo.so
instead. gcc in my case is 3.3.1, gdb 5.3.92 and kernel is 2.4.21 (not
that this should make any difference).
(Just a question to Paul Pluzhnikov: I see that you also use -fPIC
when you link main - why do you do that? On the other hand you don't
have -fPIC for the compilation, and I always thought that that's were
it's needed most.)
I guess it must be due to another strange RedHat thing. I don't know
if this might be relevant, but there's Bugzilla entry for gdb in
RedHat 8.0 (but obviously still open in July last year) about some-
one with the same problem:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86464
And there seem to have been lots of other people... In one list
I found a hint how you might get around the problem:
http://sourceforge.net/mailarchive/forum.php?thread_id=3679857&forum_id=5557
| You have to tell gdb _all_ directories to look for modules in.
| e.g. set solib-search-path
So, if you use in gdb
(gdb) set solib-search-path /path/to/to/your/library
it might help. But I am not sure if that was meant to deal with another
problem the OP there had and I can't test it since everything works fine
for me without all that...
Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.T...@physik.fu-berlin.de
\__________________________ http://www.toerring.de
Alvin Beach
> Alvin Beach wrote:
>
>> d...@snakebrook.com wrote:
>>
>>> I habe been setting a breakpoint on main, and then 'step'ing into
>>> foo(), but gdb will not allow me to step into foo.
I have also had success with KDevelop's 3.2 debugger. After creating a
custom project and setting LD_LIBRARY_PATH to include '.' I was able to
break at the call to foo() and step into it.
KDevelop's debugger, much like them all, is simply a frontend to gdb.
Have you tried using a frontend to gdb?
--
Alvin Beach
Paul Pluzhnikov
> a question to Paul Pluzhnikov: I see that you also use -fPIC
> when you link main - why do you do that? On the other hand you don't
> have -fPIC for the compilation, and I always thought that that's were
> it's needed most.)
I just repeated OPs command line "as is" from his
<1107262712.3...@z14g2000cwz.googlegroups.com> message.
The command lines are not technically correct (as I told him later),
but the original commands worked on all of my systems anyway.
Jens.T...@physik.fu-berlin.de
>> a question to Paul Pluzhnikov: I see that you also use -fPIC
>> when you link main - why do you do that? On the other hand you don't
>> have -fPIC for the compilation, and I always thought that that's were
>> it's needed most.)
> I just repeated OPs command line "as is" from his
> <1107262712.3...@z14g2000cwz.googlegroups.com> message.
> The command lines are not technically correct (as I told him later),
> but the original commands worked on all of my systems anyway.
Thanks for the clearification! When you say something about libraries
or how to use the linker I tend to believe it a lot more than what I
did until then;-)
Last2Know
I produced a toy example where I had no problem stepping into
the foo routine in the shared library and got the same error
message as you when I took the current directory out of my
LD_LIBRARY_PATH. gdb 6.1 at least will load the main executable
without having the shared library links resolved yet.
> Read my first post.
Don't be mouthy when someone is trying to help you.