Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jitendra Pawar <jitendra@linsyssoft.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] gdbserver fails on 32-bit ppc rfs running in a-64 bit 2.6 linux kernel
Date: Thu, 24 Mar 2005 13:42:00 -0000	[thread overview]
Message-ID: <1111671362.3340.67.camel@ind> (raw)
In-Reply-To: <20050323154349.GA10703@nevyn.them.org>

> 
> > Understood thanks. I believe that changing type of thread IDs to 'long
> > long' in gdbserver code will work. In that case I need to update all
> > places as you did it for changing type of thread IDs to 'unsigned long'
> > few days back. Is it the fix for this?
> 
> Why don't you explain exactly what you think is the problem, and
> exactly why you need to double the size of thread IDs to fix it?
> 

Sorry It was my mistake, I wanted to say 'long int' instead of 'long
long '.  and size of long int and unsigned int is same i.e. 64-bit.

You have commited the patch named 'Support large thread IDs in
gdbserver' at the beginning of this month. In this commit you changed
the type of thread ID to unsigned int. One of the use of This commit is
to support for 64-bit hosts and maintain consistency. The variable
cont_thread is also declared as 'unsigned int' and 'cont_thread = -1'
statement is still in the place. 

Now please see the Amit's comments:
> > > > > > > > >> 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?

So believe that changing data type of thread IDs to 'long int' will be
the fix for this.

regards
-Jitendra 


On Wed, 2005-03-23 at 10:43 -0500, Daniel Jacobowitz wrote:
> On Wed, Mar 23, 2005 at 03:27:09PM +0530, Jitendra Pawar 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.
> > > > > 
> > > 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.
> > 
> > Understood thanks. I believe that changing type of thread IDs to 'long
> > long' in gdbserver code will work. In that case I need to update all
> > places as you did it for changing type of thread IDs to 'unsigned long'
> > few days back. Is it the fix for this?
> 
> Why don't you explain exactly what you think is the problem, and
> exactly why you need to double the size of thread IDs to fix it?
> 


  reply	other threads:[~2005-03-24 13:42 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-16 16:54 Jitendra Pawar
2005-03-16 16:57 ` Daniel Jacobowitz
2005-03-22 14:11   ` Jitendra Pawar
2005-03-22 14:23     ` Daniel Jacobowitz
2005-03-22 14:50       ` Jitendra Pawar
2005-03-22 14:54         ` Daniel Jacobowitz
2005-03-23 10:03           ` Jitendra Pawar
2005-03-23 15:43             ` Daniel Jacobowitz
2005-03-24 13:42               ` Jitendra Pawar [this message]
2005-03-24 14:02                 ` Daniel Jacobowitz
2005-03-22 18:49     ` Mark Kettenis
  -- strict thread matches above, loose matches on Subject: below --
2005-03-14 16:07 Amit S. Kale
2005-03-14 16:23 ` Daniel Jacobowitz
2005-03-14 16:57   ` Christopher Faylor
2005-03-14 17:02     ` Daniel Jacobowitz
2005-03-15 13:07   ` Amit S. Kale
2005-03-16  3:16     ` Daniel Jacobowitz
2005-06-17  4:00       ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1111671362.3340.67.camel@ind \
    --to=jitendra@linsyssoft.com \
    --cc=drow@false.org \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox