From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23411 invoked by alias); 25 Oct 2011 16:53:16 -0000 Received: (qmail 23394 invoked by uid 22791); 25 Oct 2011 16:53:11 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,TW_EG X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 25 Oct 2011 16:52:57 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id B0BD52BB37A; Tue, 25 Oct 2011 12:52:56 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VS5+x+eQCKYc; Tue, 25 Oct 2011 12:52:56 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 885CF2BB371; Tue, 25 Oct 2011 12:52:56 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 89986145615; Tue, 25 Oct 2011 12:52:53 -0400 (EDT) From: Joel Brobecker To: gdb-patches@sourceware.org Cc: Joel Brobecker Subject: [RFA/commit/ia64-linux] Allow libunwind to fetch register 0 Date: Tue, 25 Oct 2011 16:55:00 -0000 Message-Id: <1319561563-20201-1-git-send-email-brobecker@adacore.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-10/txt/msg00661.txt.bz2 On ia64-linux, GDB sometimes prints the following error when trying to switch to a different task: (gdb) task 3 Register 0 is not available This is a random failure that sometimes happens, sometimes does not. We should be able to see with any program that uses thread, probably when the debugger stops the program at a certain point (which conditions trigger the problem have not been investigated). The error comes from the fact that the libunwind library is requesting the value of register 0 (zero): This eventually leads us to ia64-linux-nat.c:ia64_linux_fetch_register. This function relies on ia64_cannot_fetch_register to determine whether or not we have access to the register's value. The ptrace interface does not provide the r0 value, and so we end up telling the regcache that this register's value is not available. And yet, for r0, we do not need to ask ptrace for its value, since it is always zero. So, the fix was to add a special rule for supplying a nul value when regnum == 0. gdb/ChangeLog: * ia64-linux-nat.c (ia64_linux_fetch_register): Add special handling for r0. Tested on ia64-linux. I also tested it against the program I used to reproduce the problem. It used to consistently reproduce once every 1-10 times. Now, it doesn't anymore even after trying 50 times. OK? --- gdb/ia64-linux-nat.c | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/gdb/ia64-linux-nat.c b/gdb/ia64-linux-nat.c index 65e077b..f43e91e 100644 --- a/gdb/ia64-linux-nat.c +++ b/gdb/ia64-linux-nat.c @@ -681,6 +681,17 @@ ia64_linux_fetch_register (struct regcache *regcache, int regnum) PTRACE_TYPE_RET *buf; int pid, i; + /* r0 cannot be fetched but is always zero. */ + if (regnum == 0) + { + const char r0_value[8] = {0x00, 0x00, 0x00, 0x00, + 0x00, 0x00, 0x00, 0x00}; + + gdb_assert (sizeof (r0_value) == register_size (gdbarch, regnum)); + regcache_raw_supply (regcache, regnum, r0_value); + return; + } + if (ia64_cannot_fetch_register (gdbarch, regnum)) { regcache_raw_supply (regcache, regnum, NULL); -- 1.7.1