From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5331 invoked by alias); 14 Mar 2005 16:07:41 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 4543 invoked from network); 14 Mar 2005 16:07:33 -0000 Received: from unknown (HELO svr68.ehostpros.com) (67.15.48.48) by sourceware.org with SMTP; 14 Mar 2005 16:07:33 -0000 Received: from [61.11.18.135] (helo=pythagoras.linsyssoft.com) by svr68.ehostpros.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.44) id 1DAs6L-0005L7-80 for gdb-patches@sources.redhat.com; Mon, 14 Mar 2005 08:07:30 -0800 From: "Amit S. Kale" Organization: LinSysSoft Technologies Pvt Ltd To: GDB patches Subject: [patch] gdbserver fails on 32-bit ppc rfs running in a-64 bit 2.6 linux kernel Date: Mon, 14 Mar 2005 16:07:00 -0000 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_HbbNCisJ0DasVp1" Message-Id: <200503142137.35799.amitkale@linsyssoft.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr68.ehostpros.com X-AntiAbuse: Original Domain - sources.redhat.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - linsyssoft.com X-Source: X-Source-Args: X-Source-Dir: X-SW-Source: 2005-03/txt/msg00202.txt.bz2 --Boundary-00=_HbbNCisJ0DasVp1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-length: 593 Hi, I found that gdbserver fails on a 32-bit ppc rfs running in a 64-bit 2.6 linux kernel. The thread id's fetched from thread-db library are above 0x7fffffff. gdbserver has implicit assumptions that thread id's are "signed integers". This is true when running under a 32-bit kernel, but not true here. Attached patch fixes this problem by changing the "strtol" that scans the thread-id to "strtoul" and by changing the "cont_thread > 0" comparison to "cont_thread != -1". Is there any likelyhood of this assumption being made in some other places in gdbserver or gdb? Thanks. -Amit --Boundary-00=_HbbNCisJ0DasVp1 Content-Type: text/x-diff; charset="us-ascii"; name="threadidrange.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="threadidrange.patch" Content-length: 1685 Index: src/gdb/gdbserver/linux-low.c =================================================================== --- src.orig/gdb/gdbserver/linux-low.c 2005-03-10 19:31:24.000000000 +0530 +++ src/gdb/gdbserver/linux-low.c 2005-03-14 20:49:11.589413080 +0530 @@ -667,7 +667,7 @@ then we need to make sure we restart the other threads. We could pick a thread at random or restart all; restarting all is less arbitrary. */ - if (cont_thread > 0) + if (cont_thread != -1) { child = (struct thread_info *) find_inferior_id (&all_threads, cont_thread); @@ -1430,7 +1430,7 @@ { extern unsigned long signal_pid; - if (cont_thread > 0) + if (cont_thread != -1) { struct process_info *process; Index: src/gdb/gdbserver/server.c =================================================================== --- src.orig/gdb/gdbserver/server.c 2005-03-10 19:31:24.000000000 +0530 +++ src/gdb/gdbserver/server.c 2005-03-14 21:05:22.774770464 +0530 @@ -193,7 +193,7 @@ if (p[0] == 'S' || p[0] == 'C') { int sig; - sig = strtol (p + 1, &q, 16); + sig = strtoul (p + 1, &q, 16); if (p == q) goto err; p = q; @@ -281,7 +281,7 @@ struct thread_resume resume_info[2]; int n = 0; - if (step || sig || cont_thread > 0) + if (step || sig || cont_thread != -1) { resume_info[0].thread = ((struct inferior_list_entry *) current_inferior)->id; @@ -293,7 +293,7 @@ resume_info[n].thread = -1; resume_info[n].step = 0; resume_info[n].sig = 0; - resume_info[n].leave_stopped = (cont_thread > 0); + resume_info[n].leave_stopped = (cont_thread != -1); (*the_target->resume) (resume_info); } --Boundary-00=_HbbNCisJ0DasVp1--