From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1091 invoked by alias); 25 Mar 2004 10:29:00 -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 1068 invoked from network); 25 Mar 2004 10:28:58 -0000 Received: from unknown (HELO fela.ch) (62.167.9.67) by sources.redhat.com with SMTP; 25 Mar 2004 10:28:58 -0000 Received: from 192.168.139.154 (DHCP154 [192.168.139.154]) by fela.ch (8.9.3/8.9.3) with ESMTP id LAA13714; Thu, 25 Mar 2004 11:28:41 +0100 From: Lukas Heiniger Organization: Fela Management AG To: Daniel Jacobowitz Subject: Re: SIGTRAP or SIG32 when remote debugging threads Date: Thu, 25 Mar 2004 14:29:00 -0000 User-Agent: KMail/1.5.4 Cc: gdb@sources.redhat.com References: <200403191107.34202.lukas.heiniger@fela.ch> <200403241603.13624.lukas.heiniger@fela.ch> <20040324150746.GA26874@nevyn.them.org> In-Reply-To: <20040324150746.GA26874@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200403251129.32860.lukas.heiniger@fela.ch> X-SW-Source: 2004-03/txt/msg00255.txt.bz2 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 ?) 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?) 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. 3. After the SIG32 has appeared, I set the solib-absolute-prefix again. This time the call to svr4_current_sos returns a non-zero value for the debug_base and gdb is able to load all the libs. Lukas Heiniger