Re: SIGTRAP or SIG32 when remote debugging threads

[Lukas Heiniger <lukas.heiniger@fela.ch>]

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