This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: SIGTRAP or SIG32 when remote debugging threads
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