From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10743 invoked by alias); 25 Mar 2004 14:47:06 -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 10728 invoked from network); 25 Mar 2004 14:47:04 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 25 Mar 2004 14:47:04 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B6W8M-00010i-Ui; Thu, 25 Mar 2004 09:47:02 -0500 Date: Thu, 25 Mar 2004 15:37:00 -0000 From: Daniel Jacobowitz To: Lukas Heiniger Cc: gdb@sources.redhat.com Subject: Re: SIGTRAP or SIG32 when remote debugging threads Message-ID: <20040325144702.GA3830@nevyn.them.org> Mail-Followup-To: Lukas Heiniger , gdb@sources.redhat.com References: <200403191107.34202.lukas.heiniger@fela.ch> <200403241603.13624.lukas.heiniger@fela.ch> <20040324150746.GA26874@nevyn.them.org> <200403251129.32860.lukas.heiniger@fela.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403251129.32860.lukas.heiniger@fela.ch> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00259.txt.bz2 On Thu, Mar 25, 2004 at 11:29:32AM +0100, Lukas Heiniger wrote: > On Wednesday 24 March 2004 16:07, Daniel Jacobowitz wrote: > > On Wed, Mar 24, 2004 at 04:03:13PM +0100, Lukas Heiniger wrote: > > > On Wednesday 24 March 2004 15:39, Daniel Jacobowitz wrote: > > > > On Wed, Mar 24, 2004 at 02:11:16PM +0100, Lukas Heiniger wrote: > > > > > It looks like setting and hitting the shlib event breakpoint works. > > > > > > > > Not to me. Is 0x40002570 the shlib event breakpoint, and if so, why > > > > are you stopped there instead of at the first instruction in the > > > > program? > > > > > > According to 'maint info breakpoints' (you can find it approximately in > > > the middle of my last session) the shlib event breakpoint is located at > > > 0x4000c3fc. After entering 'continue', gdb seems to set a breakpoint > > > there. The instruction is restored after SIG32 has been received. > > > > > > I think that 0x40002570 actually is the first instruction in the program. > > > > In that case the breakpoint was not hit, just set, according to your > > log. > > > Yeah, you're right (of course). Let me see if I got the mechanisms right (I > hope I don't go to much into details): > > 1. When I start the gdb (i.e. when I type 'target remote /dev/ttyS0'), it will > try to set a break point in the dynamic linker (creating an inferior hook). > When this special breakpoint was hit, gdb would examine the linker and load > in any shared libs. > > 2. Setting the shlib bp is done by enable_break. enable_break first assumes > that the target is running > > (is this the case in remote debugging ?) It should be. > and tries to get the dynamic linker base from the shared library table. This > fails because the inferior returns 0 for the debug_base in svr4_current_sos. > So (comment from the code): /* Otherwise we find the dynamic linker's base > address by examining the current pc (which should point at the entry point > for the dynamic linker) and subtracting the offset of the entry point. */ > > (Isn't pc pointing at the first instruction of the program?) No, the program is invoked by the dynamic linker. > so enable_break calculates some value for the breakpoint, which in my case is > 0x4000c3fc. For whatever reason this bp is not hit before the SIG32 appears. > If this really is the problem, I have no Idea what I could do about it. You need to figure out if the breakpoint is at the right place or not. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer