From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4921 invoked by alias); 25 Feb 2005 20:20:04 -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 4467 invoked from network); 25 Feb 2005 20:19:13 -0000 Received: from unknown (HELO nimbus.ott.qnx.com) (209.226.137.76) by sourceware.org with SMTP; 25 Feb 2005 20:19:13 -0000 Received: from [10.12.1.181] (dhcpa181.ott.qnx.com [10.12.1.181]) by nimbus.ott.qnx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F1F6V21P; Fri, 25 Feb 2005 15:18:09 -0500 Message-ID: <421F86A4.3020400@qnx.com> Date: Fri, 25 Feb 2005 21:00:00 -0000 From: Kris Warkentin User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) MIME-Version: 1.0 To: Hareesh Nagarajan CC: GDB Subject: Re: Unable to find dynamic linker breakpoint function. References: <421F7E59.7020400@cs.uic.edu> In-Reply-To: <421F7E59.7020400@cs.uic.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-02/txt/msg00165.txt.bz2 Hareesh Nagarajan wrote: >I have compiled libstdc++ with '-g -fomit-frame-pointer'. > >Additionally, I use Gentoo Linux and that this problem of mine affects >debugging member functions of C++ STL containers. So how could the wrong > >glibc be the problem? > > Actually, I was being dumb. I forgot that Linux has the runtime linker in ld-linux.so. On QNX, our linker is in our libc. I just wanted to be sure that what your program was loading at runtime was exactly the same as what gdb was reading - hence the 'info shared'. >I have no idea how to fix this problem and it is frankly driving me mad! > Looks like it has nothing to do with your special libs. I just tried to reproduce your problem and got this: (gdb) p foo.at(2) $1 = (const char &) @0x90f6016: 108 'l' (gdb) p foo.at(2) Program received signal SIGTRAP, Trace/breakpoint trap. 0x00d27ef1 in std::string::at () from /usr/lib/libstdc++.so.5 The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use "set unwindonsignal on" Evaluation of the expression containing the function (std::string::at(unsigned i nt) const) will be abandoned. (gdb) It worked the first time and then failed the second time. Looks like the dummy frame and supporting breakpoints are left over: (gdb) maint info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x08048905 in main at seeplus.cc:8 breakpoint already hit 1 time -2 shlib events keep y 0x006f44a0 <_dl_debug_state> breakpoint already hit 3 times -10 longjmp keep n 0x006f7920 -11 longjmp keep n 0x00727c60 -12 longjmp keep n 0x00727c60 -13 longjmp resume keep n 0x00000000 0 call dummy del y 0x08048844 <_start> stop only in stack frame at 0xbfe8300c Ick. If I put 'set unwindsignal on', at least the program isn't hosed when it chokes. Looks like the same problem as PR:1766: http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=1766&return_url=http%3A%2F%2Fsources.redhat.com%2Fcgi-bin%2Fgnatsweb.pl%3Fdatabase%3Dgdb%26category%3Dc%252B%252B%26severity%3Dall%26priority%3Dall%26responsible%3Dall%26submitter_id%3Dall%26state%3Dall%26ignoreclosed%3DIgnore%2520Closed%26class%3Dall%26synopsis%3D%26multitext%3D%26columns%3Dcategory%26columns%3Dstate%26columns%3Dclass%26columns%3Dresponsible%26columns%3Dsynopsis%26displaydate%3DDisplay%2520Current%2520Date%26cmd%3Dsubmit%2520query%26sortby%3DResponsible%26.cgifields%3Ddisplaydate%26.cgifields%3Dignoreclosed%26.cgifields%3Doriginatedbyme%26.cgifields%3Dcolumns Don't know what else to tell you. Known problem. Don't do that. We'll fix it RSN. Sorry. cheers, Kris