From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20779 invoked by alias); 23 May 2005 06:02:08 -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 20772 invoked by uid 22791); 23 May 2005 06:02:04 -0000 Received: from ausmtp02.au.ibm.com (HELO ausmtp02.au.ibm.com) (202.81.18.187) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 23 May 2005 06:02:04 +0000 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp02.au.ibm.com (8.12.10/8.12.10) with ESMTP id j4N5vZ2F057432 for ; Mon, 23 May 2005 15:57:35 +1000 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.250.237]) by sd0208e0.au.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4N64bL3127846 for ; Mon, 23 May 2005 16:04:37 +1000 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.12.11/8.13.3) with ESMTP id j4N61iB5006096 for ; Mon, 23 May 2005 16:01:44 +1000 Received: from plinuxt18.cn.ibm.com (plinuxt18.cn.ibm.com [9.181.140.28]) by d23av04.au.ibm.com (8.12.11/8.12.11) with ESMTP id j4N61gkj006042; Mon, 23 May 2005 16:01:43 +1000 Date: Mon, 23 May 2005 11:21:00 -0000 From: Wu Zhou To: Daniel Jacobowitz cc: Manoj Iyer , gdb-patches@sources.redhat.com Subject: Re: [RFC] gdb.server testcases (resend) In-Reply-To: <20050522171520.GA1223@nevyn.them.org> Message-ID: References: <1116490026.428c492a8f3d8@imap.linux.ibm.com> <20050522171520.GA1223@nevyn.them.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2005-05/txt/msg00512.txt.bz2 > Yes, this will not work. The correct way to handle this is to wait > until I have implemented the available target features proposal I've > posted on gdb@, and then I can make gdbserver inform GDB that 64-bit > registers are available so that it will expect them. So you are going to add a command for gdbserver to notify remote gdb the availability of 64-bit registers? That is good. But I am also thinking of other ways. The first solution I thought of is to let gdbserver choose which set of registers to use according to the arch (32-bit or 64-bit) of the debuggee. The other solution I could thought of is to let host-side gdb accept 64-bit register as well. I even tried some coding with the second method. It seems that it worked sorta, at least I can set breakpoint, continue the process and so on. But I did met problems with "next" and "step" commands, which didn't go on with executing the process at all. Because I am not that familar with the code of gdb/gdbserver, so I am not very sure where to find the root cause of these problems. I am also not sure whether these two methods are workable? Would you please help evaluate this? If it is really workable, what is the pros and cons of these methods compared to your proposal? Thanks a lot! > This will require some surgery in GDB, I'm sure. The way MIPS > implements this is not very reliable. > > > Program received signal SIGFPE, Arithmetic exception. > > 0x000000800013fd64 in .vfprintf () from /lib64/tls/libc.so.6 > > (gdb) > > > > I have no idea what causes this one, sorry. That SIGFPE error disappeared after applying your patch to latest GDB cvs tree. But I met with another strange problem when debugging gdb.base/break, which defines the following function: int factorial (value) int value; #endif { if (value > 1) { /* set breakpoint 7 here */ value *= factorial (value - 1); } return (value); /* set breakpoint 19 here */ } normally factorial(6) will recursively call itself 5 times and return 720. However while using 64-bit gdbserver on 64-bit binary, it doesn't call factorial(5) at all, return directly 6 as the result. I am suspecting that "value > 1" doesn't get executed, so I change the conditional statement to "if (value - 1)", it worked! So it turn out that "value > 1" always return 0 in this running context. That is really odd. Any clues you could thought of? Thanks in advance. Cheers - Wu Zhou