Re: SIGTRAP or SIG32 when remote debugging threads

[Daniel Jacobowitz <drow@false.org>]

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