From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23491 invoked by alias); 21 Nov 2003 16:34: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 23484 invoked from network); 21 Nov 2003 16:34:58 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 21 Nov 2003 16:34:58 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1ANEFG-00074i-1g for ; Fri, 21 Nov 2003 11:34:58 -0500 Date: Fri, 21 Nov 2003 16:34:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Re: hacking shlib/dlopened breakpoints Message-ID: <20031121163457.GA27120@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com References: <20031121125502.GA7194@skynet.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031121125502.GA7194@skynet.ie> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-11/txt/msg00199.txt.bz2 On Fri, Nov 21, 2003 at 12:55:02PM +0000, Caolan McNamara wrote: > I'm looking at breakpoints in dlopened libraries at the moment, > setting a breakpoint after my library is dlopened works of course > and, as in the example below, I see that gdb can move the address of > the breakpoint in the .so when it is unloaded and reloaded during > execution, but on re-execution of the little program I get > " > Warning: > Cannot insert breakpoint X. > Error accessing memory address 0xe8535a: Input/output error. > " > > Naturally the library isn't loaded at the start of re-execution, but I > hoped that the the breakpoint state would change to bp_shlib_disabled > and get reenabled when the .so reappears. > > So I dig a little and see that this will only happen if > (DISABLE_UNSETTABLE_BREAK (b->address)) is true. But that queries to > see if the address is a valid loaded address, which it isn't anymore. > I naively turned this to if (1) to see what would happen, and was > happy to see this worked, the breakpoint in the .so gets re-enabled > and set to its new address when the affected .so reappears, and gdb > stops in it correctly. Could you try a current CVS snapshot? I just made a change in this area to fix another problem with dlopen'd librares. > But sadly when I continue everything only works as far as the dlclose > of that .so where I get... > Program received signal SIGSEGV, Segmentation fault. > Cannot remove breakpoints because program is no longer writable. > It might be running in another process. > Further execution is probably impossible. > 0x008c4ea4 in _dl_debug_state_internal () from /lib/ld-linux.so.2 > > Any ideas/hints as to how to make it work, or what exactly might the > cause of my exciting crash above ? The reason I'm fiddling with this Probably something else was loaded over the same space. Or GDB's breakpoint list got hosed. > is that I'm really after a working deferred break/future-break in gdb > to make debugging apps like OpenOffice/Mozilla with mountains of > dynamically loaded components a lot easier. See Jeff's recent post on this topic... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer