Re: pthread_create does not return when remote debugging

[Jon Ringle <jon.ringle@comdial.com>]

On Saturday 28 June 2003 07:54 pm, Daniel Jacobowitz wrote:
> On Sat, Jun 28, 2003 at 06:33:53PM -0400, Jon Ringle wrote:
> > On Saturday 28 June 2003 04:01 pm, Daniel Jacobowitz wrote:
> > > On Sat, Jun 28, 2003 at 01:11:06PM -0400, Jon Ringle wrote:
> > > > > > Could the problem be on the gdbserver side not sending back
> > > > > > anything in response to gdb Sending packet: &c#63...Ack?
> > > > >
> > > > > No.  That's a continue request.  The target isn't stopping again,
> > > > > but that's not gdbserver's fault... it won't respond to the client
> > > > > until the program stops.
> > > > >
> > > > > Find out why it's not stopping...
> > > >
> > > > I turned on remote_debug = 1, and debug_threads = 1 on gdbserver, and
> > > > I get the following on the target when I continue. The signal 32
> > > > looks suspect to me.
> > >
> > > It is correct.  The thread manager uses that.  What are you running on
> > > the ARM board?  What's the rest of the gdbserver log?
> >
> > The ARM board is running linux-2.2.16 w/ glibc-2.1.3. The arm-linux-gcc
> > version is 2.95.2.
>
> Gdbserver is issuing a single-step request.  ARM doesn't have
> single-step support in hardware, generally, so the kernel emulates it.
> This behaviour almost certainly represents a problem with your kernel's
> single-step implementation.  One possible problem would be if your
> compiler is using the "bx" instruction to return from functions; most
> versions of the kernel can't single-step a bx instruction.
>
> Here's a tweak to gdbserver which will prevent it from trying to
> single-step in your case.  Let me know if this works, please.

You da man! It worked.

What's interesting though, is that if I used the arm gdb-cross/gdb/gdb on the 
arm board, this worked just fine. It appears that gdb handles this situation 
ok as is. Does gdb handle this the way that your patch for gdbserver does?

Jon