From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20160 invoked by alias); 21 Oct 2003 14:56:58 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20129 invoked from network); 21 Oct 2003 14:56:57 -0000 Received: from unknown (HELO upsn231.cri.u-psud.fr) (129.175.34.231) by sources.redhat.com with SMTP; 21 Oct 2003 14:56:57 -0000 Received: from ikaria.inria-futurs.pcri.u-psud.fr (ikaria.inria-futurs.pcri.u-psud.fr [129.175.144.36]) by upsn231.cri.u-psud.fr (8.12.8/8.12.0.Beta10) with ESMTP id h9LEtc5m022745; Tue, 21 Oct 2003 16:55:38 +0200 Received: from inria.fr (localhost [127.0.0.1]) by ikaria.inria-futurs.pcri.u-psud.fr (8.11.1/8.11.1) with ESMTP id h9LEuqw28059; Tue, 21 Oct 2003 16:56:52 +0200 Message-ID: <3F954934.7080107@inria.fr> Date: Tue, 21 Oct 2003 14:56:00 -0000 From: Marc Gonzalez-Sigler User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Elizabeth Chastain CC: gdb@sources.redhat.com Subject: Re: gdb steps into glibc functions References: <200310211419.h9LEJluk018502@duracef.shout.net> In-Reply-To: <200310211419.h9LEJluk018502@duracef.shout.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned: by amavis X-Spam-Status: score=-33.2 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA autolearn=ham version=2.53 X-Spam-Level: X-Spam-Score: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-SW-Source: 2003-10/txt/msg00236.txt.bz2 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