Re: [patch] gdbserver fails on 32-bit ppc rfs running in a-64 bit 2.6 linux kernel

[Daniel Jacobowitz <drow@false.org>]

On Tue, Mar 22, 2005 at 08:14:09PM +0530, Jitendra Pawar wrote:
> On Tue, 2005-03-22 at 09:23 -0500, Daniel Jacobowitz wrote:
> > On Tue, Mar 22, 2005 at 07:35:24PM +0530, Jitendra Pawar wrote:
> > >  
> > > > > >On Tue, Mar 15, 2005 at 06:36:22PM +0530, Amit S. Kale wrote:
> > > > > >> The strtoul change in my patch was already present. Sorry about that.
> > > > > >> 
> > > > > >> You have changed the data type of thread_resume::thread as well as cont_thread 
> > > > > >> to unsigned long. "cont_thread = -1" and "(cont_thread > 0)" are still in 
> > > > > >> place. How does this work?
> > > 
> > > There are about 15 files in gdb source have statement pid_to_ptid (-1);
> > > which finally returns -1 to server. Is it OK to replace  -1 with 0 ? I
> > > would like to know significance of returning pid -1, 0 and positive
> > > integer.
> > 
> > Amit's original issue is in gdbserver; how do any of the invalid GDB
> > pids get sent over the wire to gdbserver?  That shouldn't happen.
> > 
> 
> So can I say that GDB never written pid with -1 value to gdbserver?  OR
> do I need to find only those statements form GDB that returns -1 to
> gdbserver? If this is the case then whether replacing those '-1' with
> '0' will be the solution for this?  

I don't know.  But you're barking up the wrong tree; whatever you need
to change, you should be doing it only within gdbserver.  If you change
GDB to fix a problem in gdbserver, you're changing the remote protocol.

-- 
Daniel Jacobowitz
CodeSourcery, LLC