From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27295 invoked by alias); 5 Sep 2009 00:25:33 -0000 Received: (qmail 27261 invoked by uid 22791); 5 Sep 2009 00:25:32 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 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; Sat, 05 Sep 2009 00:25:26 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 190F92BAC03; Fri, 4 Sep 2009 20:25:24 -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 zFRxIjz77yqo; Fri, 4 Sep 2009 20:25:24 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id B5CA42BAACC; Fri, 4 Sep 2009 20:25:23 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 84F5CF589B; Fri, 4 Sep 2009 17:25:20 -0700 (PDT) Date: Sat, 05 Sep 2009 00:25:00 -0000 From: Joel Brobecker To: Hui Zhu Cc: gdb@sourceware.org, Michael Snyder Subject: Re: [gdb-7.0 release] 2009-09-02 status and proposed plan Message-ID: <20090905002520.GA19729@adacore.com> References: <20090902164425.GR4379@adacore.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00100.txt.bz2 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1025 Hui, > I had post a patch for it. It still in discussion. > http://sourceware.org/ml/gdb-patches/2009-08/msg00574.html As far as I can tell, you received some feedback from one of the maintainers (Mark Kettenis) about your patch: http://sourceware.org/ml/gdb-patches/2009-08/msg00584.html I also looked at your patch before looking at the replies, and I had the same comments as Jiang and Mark. The casts in this raised a red flag, and I don't see why we should need them. Would it make sense to define a type syscall_t that's either an int or an unsigned int, and use that consistently throughout? Otherwise, another simpler option would be to just use either int or unsigned int without using a typedef. In the meantime, I think you can get away from this all by using regcache_raw_write_signed. Read the syscall ID as a signed number, all should be fine. I'm attaching a patch that fixes the build issue an illustrates this suggestion. Can you please give it a test and resubmit if it works for you? -- Joel --GvXjxJ+pjyke8COw Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="syscall-cygwin-64bit.diff" Content-length: 1184 Index: i386-linux-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/i386-linux-tdep.c,v retrieving revision 1.66 diff -u -p -r1.66 i386-linux-tdep.c --- i386-linux-tdep.c 10 Aug 2009 03:04:44 -0000 1.66 +++ i386-linux-tdep.c 5 Sep 2009 00:24:25 -0000 @@ -367,18 +367,19 @@ static int i386_linux_intx80_sysenter_record (struct regcache *regcache) { int ret; - uint32_t tmpu32; + LONGEST syscall_num; - regcache_raw_read (regcache, I386_EAX_REGNUM, (gdb_byte *) &tmpu32); + regcache_raw_read_signed (regcache, I386_EAX_REGNUM, &syscall_num); - if (tmpu32 > 499) + if (syscall_num > 499) { - printf_unfiltered (_("Process record and replay target doesn't " - "support syscall number %u\n"), tmpu32); + printf_unfiltered (_("Process record and replay target does not " + "support syscall number %s\n"), + plongest (syscall_num)); return -1; } - ret = record_linux_system_call (tmpu32, regcache, + ret = record_linux_system_call (syscall_num, regcache, &i386_linux_record_tdep); if (ret) return ret; --GvXjxJ+pjyke8COw--