Re: Unable to find dynamic linker breakpoint function.

[Kris Warkentin <kewarken@qnx.com>]

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 <longjmp>
-11 longjmp        keep n   0x00727c60 <siglongjmp>
-12 longjmp        keep n   0x00727c60 <siglongjmp>
-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