From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27263 invoked by alias); 5 Jan 2006 14:17:09 -0000 Received: (qmail 27255 invoked by uid 22791); 5 Jan 2006 14:17:09 -0000 X-Spam-Check-By: sourceware.org Received: from qnxmail.qnx.com (HELO nimbus.ott.qnx.com) (209.226.137.76) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 05 Jan 2006 14:17:02 +0000 Received: by nimbus.ott.qnx.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jan 2006 09:17:00 -0500 Message-ID: <3518719F06577C4F85DA618E3C37AB9101CFC9FC@nimbus.ott.qnx.com> From: Kris Warkentin To: 'Anthony Heading' , gdb@sources.redhat.com Subject: RE: debugging shared libraries Date: Thu, 05 Jan 2006 14:17:00 -0000 MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00019.txt.bz2 Hi Anthony, GDB has support for deferred breakpoints. Try: gdb my_executable (gdb) break my_buggy_shared_library_function() (gdb) blah blah not found would you like to defer this? y (gdb) r Then gdb loads the shared libraries (based on information in the runtime image of the executable) and sets the breakpoint. That should work. cheers, Kris > -----Original Message----- > From: gdb-owner@sourceware.org > [mailto:gdb-owner@sourceware.org] On Behalf Of Anthony Heading > Sent: Thursday, January 05, 2006 9:12 AM > To: gdb@sources.redhat.com > Subject: debugging shared libraries > > Hello, > > Happy New Year to all. > > I know this is an old question, but (probably in a bout of > fresh New Year optimism) I hopefully tried the following: > > ~% gdb y.so > GNU gdb 6.4-debian > Copyright 2005 Free Software Foundation, Inc. > [...] > > (gdb) break my_buggy_shared_library_function() > Breakpoint 1 at 0x792: file y.cpp, line 5. > (gdb) run my_executable > Starting program: /home/ajrh/y.so my_executable Breakpoint 1 > at 0x80000792: file y.cpp, line 5. > warning: shared library handler failed to enable breakpoint > > Command syntax aside, can GDB really not DWIM? Starting GDB > on the .so seems like the right thing to do: the > tab-completion etc on the function names works to get > breakpoints set up, etc. But if the debug target is a shared > library then I probably need to run a different executable to > get the process started. > > (gdb) help file > Use FILE as program to be debugged. > It is read for its symbols, for getting the contents of pure > memory, and it is the program executed when you use the `run' command. > > Equivalently, I think, do these two properties really need to > be hardwired together? > > For reference, I think this works to my gratification in MS > Visual Studio on Win32: if you try to debug a DLL, the > program prompts to ask which executable you'd like to start. > > Regards > > Anthony >