Gdbserver + RH9

Gdbserver + RH9

[Urrutikoetxea, Eduardo]

Hi all,

We are trying to remote-debug (fresh gdb 6.1.1) a multithread program
running on RH9, both host and target.
As soon as the second thread starts, we get:

"Cannot find new threads: generic error" on the target

and  "Ignoring packet error, continuing..." on the host.

gdb never finds more than one thread when querying with "info threads".

But, everything goes smooth when using gdb on one platform, not remote.

Does anybody know if this is a NPTL/LinuxThreads issue ? and if this
configuration is supported  / will it be supported ?

Thanks & regards

Eduardo



***********************************************************************************************
The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. 

This mail or any response may be monitored by Sony United Kingdom Limited. (6)
***********************************************************************************************

Re: Gdbserver + RH9

[Daniel Jacobowitz]

On Thu, Jul 15, 2004 at 02:08:01PM +0100, Urrutikoetxea, Eduardo wrote:
> 
> Hi all,
> 
> We are trying to remote-debug (fresh gdb 6.1.1) a multithread program
> running on RH9, both host and target.
> As soon as the second thread starts, we get:
> 
> "Cannot find new threads: generic error" on the target
> 
> and  "Ignoring packet error, continuing..." on the host.
> 
> gdb never finds more than one thread when querying with "info threads".
> 
> But, everything goes smooth when using gdb on one platform, not remote.
> 
> Does anybody know if this is a NPTL/LinuxThreads issue ? and if this
> configuration is supported  / will it be supported ?

Gdbserver does not support NPTL.  It can not support NPTL without
changes in the remote protocol, and no agreement was ever reached on
how to implement them.

-- 
Daniel Jacobowitz

Re: Gdbserver + RH9

[Andrew Cagney]

> Gdbserver does not support NPTL.  It can not support NPTL without
> changes in the remote protocol, and no agreement was ever reached on
> how to implement them.

There was agreement.  It should adopt the `F' model.

Andrew

Re: Gdbserver + RH9

[Daniel Jacobowitz]

On Fri, Jul 16, 2004 at 10:12:32AM -0400, Andrew Cagney wrote:
> 
> >Gdbserver does not support NPTL.  It can not support NPTL without
> >changes in the remote protocol, and no agreement was ever reached on
> >how to implement them.
> 
> There was agreement.  It should adopt the `F' model.

I didn't agree, so I have trouble calling that agreement.  My last
message with an opinion was:
  http://sources.redhat.com/ml/gdb/2004-03/msg00111.html

-- 
Daniel Jacobowitz

Re: Gdbserver + RH9

[Andrew Cagney]

You wrote:
http://sources.redhat.com/ml/gdb/2004-03/msg00120.html
> Anyway, let me take a stab at implementing it the way you described.
> I still think it's overkill, but I may be able to work out a way to do
> it.

Re: Gdbserver + RH9

[Daniel Jacobowitz]

On Fri, Jul 16, 2004 at 10:27:28AM -0400, Andrew Cagney wrote:
> You wrote:
> http://sources.redhat.com/ml/gdb/2004-03/msg00120.html
> >Anyway, let me take a stab at implementing it the way you described.
> >I still think it's overkill, but I may be able to work out a way to do
> >it.

I think it's fairly clear that my message is resignation, not
agreement. I was unable to persuade you to accept the simpler protocol
that I had tested, and since then I have not been able to work out a
practical way to implement the more complicated solution without
rewriting all of gdbserver.  Which I am not especially interested in
doing, and would not be able to test without adding fault injection to
GDB, since there is no reasonable way to interrupt a symbol lookup
anyway.

-- 
Daniel Jacobowitz