gdb steps into glibc functions

gdb steps into glibc functions

[Marc Gonzalez-Sigler]

Hi all,

I have the following system:

$ uname -a
Linux ikaria 2.4.16 #1 Wed Jan 9 15:04:38 CET 2002 i686 unknown

$ gdb -v
GNU gdb 5.0rh-5 Red Hat Linux 7.1
Copyright 2001 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-redhat-linux".

When I use the step command in gdb, it seems that gdb tries to step 
into glibc functions.


325         a2b = (strcmp (progname, "ir_a2b") == 0);
(gdb) step
strcmp (p1=0xbfffface "ir_b2a", p2=0x80ed99f "ir_a2b") at 
../sysdeps/generic/strcmp.c:33
33      ../sysdeps/generic/strcmp.c: No such file or directory.
         in ../sysdeps/generic/strcmp.c
Current language:  auto; currently c


This does not happen on my home computer: even when I use the step 
command, gdb steps over glibc calls.

Does it mean that glibc was compiled with debugging information on 
this Redhat system? And gdb complains because it cannot find the 
source code?

If this is the case, then I would obtain the behavior I am used to 
as soon as I use a version of glibc which was compiled without 
debugging information, no? Could I just strip the library?

One last question: once I enter a function, say, strcmp(), is finish 
the correct command to jump out of the function?

Marc

Re: gdb steps into glibc functions

[Daniel Jacobowitz]

On Tue, Oct 21, 2003 at 12:48:01PM +0200, Marc Gonzalez-Sigler wrote:
> Hi all,
> 
> I have the following system:
> 
> $ uname -a
> Linux ikaria 2.4.16 #1 Wed Jan 9 15:04:38 CET 2002 i686 unknown
> 
> $ gdb -v
> GNU gdb 5.0rh-5 Red Hat Linux 7.1
> Copyright 2001 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-redhat-linux".
> 
> When I use the step command in gdb, it seems that gdb tries to step 
> into glibc functions.
> 
> 
> 325         a2b = (strcmp (progname, "ir_a2b") == 0);
> (gdb) step
> strcmp (p1=0xbfffface "ir_b2a", p2=0x80ed99f "ir_a2b") at 
> ../sysdeps/generic/strcmp.c:33
> 33      ../sysdeps/generic/strcmp.c: No such file or directory.
>         in ../sysdeps/generic/strcmp.c
> Current language:  auto; currently c
> 
> 
> This does not happen on my home computer: even when I use the step 
> command, gdb steps over glibc calls.
> 
> Does it mean that glibc was compiled with debugging information on 
> this Redhat system? And gdb complains because it cannot find the 
> source code?

Yep.

> If this is the case, then I would obtain the behavior I am used to 
> as soon as I use a version of glibc which was compiled without 
> debugging information, no? Could I just strip the library?

Yep.  Or you could "set auto-solib-add 0" if you don't need to debug
threads or any other functions in shared libraries; that'll do it too.

> One last question: once I enter a function, say, strcmp(), is finish 
> the correct command to jump out of the function?

That's right.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb steps into glibc functions

[Michael Elizabeth Chastain]

Hi Marc,

Whoops, I didn't know you were on ia64.  Yeah, you can't just upgrade
to Red Hat Linux 9 for that.

	$ ldd /orc-2.1/usr/ia64-orc-linux/bin/ir_b2a
	libm.so.6 => /lib/libm.so.6 (0x40028000)
	libc.so.6 => /lib/libc.so.6 (0x4004a000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Interesting, so the system libc.so.6 is providing the symbols,
so it would be delicate to take them out.  Good idea to leave
them alone!

Michael C

Re: gdb steps into glibc functions

[Marc Gonzalez-Sigler]

Hi,

First of all, I thank you and Daniel for answering my question. 
Daniel's suggestion to set auto-solib-add to 0 proved very useful.

Michael Elizabeth Chastain wrote:
> Hello,
> 
> 
>>GNU gdb 5.0rh-5 Red Hat Linux 7.1
> 
> 
> That is a very old gdb, and a very old Red Hat Linux, too.
> 
> The current releases are: gdb 6.0 and Red Hat Linux 9.

Unfortunately, I have no control over this.

> Look at the value of the environment variable LD_LIBRARY_PATH.
> In particular, see if there is a "/usr/lib/debug" in there.
> Red Hat ships the normal non-debug version of glibc in /lib,
> and the debugging version in /usr/lib/debug.  I don't know if
> it was that way back in 7.1, but it likely was.

$ echo $LD_LIBRARY_PATH
/usr/lib:/orc-2.1/usr/ia64-orc-linux/lib/gcc-lib/ia64-orc-linux/2.1

$ ls /usr/lib/debug
ls: /usr/lib/debug: No such file or directory

> Also try "ldd program" on your program and see how the glibc
> reference is getting resolved.

$ ldd /orc-2.1/usr/ia64-orc-linux/bin/ir_b2a
	libm.so.6 => /lib/libm.so.6 (0x40028000)
	libc.so.6 => /lib/libc.so.6 (0x4004a000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

$ ls -l /lib/libc.*
lrwxrwxrwx    1 root     root           13 Mar 13  2002 
/lib/libc.so.6 -> libc-2.2.4.so

$ ls -l /lib/libc-2.2.4.so
-rwxr-xr-x    1 root     root      5723311 Dec  8  2001 
/lib/libc-2.2.4.so

> You can probably strip the library with "strip --strip-debug"
> but it's tricky to do *anything* to glibc on a running system,
> because all the processes on the system have mmap'ed that file.
> If you could boot from a CD-ROM then it would be safer to modify
> glibc.  And for your sake, make a backup of the original glibc in
> another directory before you touch glibc.

I think I will stick with Daniel's solution :-)

> Also, use "next" instead of "step".  "next" always skips over the
> function.  That would give you the behavior you want, without having
> to change anything.

Not really. I do want to step into my code, not the glibc code.

Marc

Re: gdb steps into glibc functions

[Michael Elizabeth Chastain]

Hello,

> GNU gdb 5.0rh-5 Red Hat Linux 7.1

That is a very old gdb, and a very old Red Hat Linux, too.

The current releases are: gdb 6.0 and Red Hat Linux 9.

> Does it mean that glibc was compiled with debugging information on 
> this Redhat system? And gdb complains because it cannot find the 
> source code?

Yes, it looks like that is happening.  Your gdb mentions the
source file name and line number for the glibc function,
which means that the source file name must be in glibc.

> If this is the case, then I would obtain the behavior I am used to 
> as soon as I use a version of glibc which was compiled without 
> debugging information, no? Could I just strip the library?

Look at the value of the environment variable LD_LIBRARY_PATH.
In particular, see if there is a "/usr/lib/debug" in there.
Red Hat ships the normal non-debug version of glibc in /lib,
and the debugging version in /usr/lib/debug.  I don't know if
it was that way back in 7.1, but it likely was.

The solution to your problem might be as easy as taking
"/usr/lib/debug" out of LD_LIBRARY_PATH.

Also try "ldd program" on your program and see how the glibc
reference is getting resolved.

You can probably strip the library with "strip --strip-debug"
but it's tricky to do *anything* to glibc on a running system,
because all the processes on the system have mmap'ed that file.
If you could boot from a CD-ROM then it would be safer to modify
glibc.  And for your sake, make a backup of the original glibc in
another directory before you touch glibc.

> One last question: once I enter a function, say, strcmp(), is finish 
> the correct command to jump out of the function?

Yes.

Also, use "next" instead of "step".  "next" always skips over the
function.  That would give you the behavior you want, without having
to change anything.

Hope this helps,

Michael C