From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3122 invoked by alias); 10 May 2009 23:51:26 -0000 Received: (qmail 3110 invoked by uid 22791); 10 May 2009 23:51:24 -0000 X-Spam-Check-By: sourceware.org Received: from pool-173-76-57-218.bstnma.fios.verizon.net (HELO cgf.cx) (173.76.57.218) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 10 May 2009 23:51:19 +0000 Received: from ednor.cgf.cx (ednor.casa.cgf.cx [192.168.187.5]) by cgf.cx (Postfix) with ESMTP id B7C2E13C023; Sun, 10 May 2009 19:51:09 -0400 (EDT) Received: by ednor.cgf.cx (Postfix, from userid 201) id AF6EE2B679; Sun, 10 May 2009 19:51:09 -0400 (EDT) Date: Sun, 10 May 2009 23:51:00 -0000 From: Christopher Faylor To: gdb-patches@sourceware.org, Hui Zhu Subject: Re: [Prec/RFA] fix build error of prec in cygwin Message-ID: <20090510235109.GD25909@ednor.casa.cgf.cx> Mail-Followup-To: gdb-patches@sourceware.org, Hui Zhu References: <20090510174809.GA25909@ednor.casa.cgf.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) 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: 2009-05/txt/msg00198.txt.bz2 On Mon, May 11, 2009 at 02:07:29AM +0800, Hui Zhu wrote: >On Mon, May 11, 2009 at 01:48, Christopher Faylor > wrote: >> On Mon, May 11, 2009 at 01:31:18AM +0800, Hui Zhu wrote: >>>--- a/i386-linux-tdep.c >>>+++ b/i386-linux-tdep.c >>>@@ -586,6 +586,14 @@ static int i386_linux_sc_reg_offset[] = >>> #define I386_LINUX_RECORD_IOCTL_TIOCSHAYESESP ? ? ? ? 0x545F >>> #define I386_LINUX_RECORD_IOCTL_FIOQSIZE ? ? ? ? ? ? ?0x5460 >>> >>>+/* The values of the second argument of system call "sys_fcntl" >>>+ ? and "sys_fcntl64". ?The values of these macros were obtained from >>>+ ? Linux Kernel source. ?*/ >>>+#define I386_LINUX_RECORD_FCNTL_F_GETLK ? ? ? ? ? ? ? ? ? ? ? 5 >>>+#define I386_LINUX_RECORD_FCNTL_F_GETLK64 ? ? ? ? ? ? 12 >>>+#define I386_LINUX_RECORD_FCNTL_F_SETLK64 ? ? ? ? ? ? 13 >>>+#define I386_LINUX_RECORD_FCNTL_F_SETLKW64 ? ? ? ? ? ?14 >>>+ >>> static void >>> i386_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch) >>> { >>>@@ -781,6 +789,12 @@ i386_linux_init_abi (struct gdbarch_info >>> ? ? I386_LINUX_RECORD_IOCTL_TIOCSHAYESESP; >>> ? i386_linux_record_tdep.ioctl_FIOQSIZE = I386_LINUX_RECORD_IOCTL_FIOQSIZE; >>> >>>+ ?i386_linux_record_tdep.fcntl_F_GETLK = I386_LINUX_RECORD_FCNTL_F_GETLK; >>>+ ?i386_linux_record_tdep.fcntl_F_GETLK64 = I386_LINUX_RECORD_FCNTL_F_GETLK64; >>>+ ?i386_linux_record_tdep.fcntl_F_SETLK64 = I386_LINUX_RECORD_FCNTL_F_SETLK64; >>>+ ?i386_linux_record_tdep.fcntl_F_SETLKW64 = >>>+ ? ?I386_LINUX_RECORD_FCNTL_F_SETLKW64; >>>+ >>> ? i386_linux_record_tdep.arg1 = I386_EBX_REGNUM; >>> ? i386_linux_record_tdep.arg2 = I386_ECX_REGNUM; >>> ? i386_linux_record_tdep.arg3 = I386_EDX_REGNUM; >>>--- a/linux-record.c >>>+++ b/linux-record.c >>>@@ -394,7 +394,7 @@ record_linux_system_call (int num, struc >>> ? ? ? { >>> ? ? ? ? printf_unfiltered (_("Process record and replay target doesn't " >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"support ioctl request 0x%08x.\n"), >>>- ? ? ? ? ? ? ? ? ? ? ? ? ? tmpu32); >>>+ ? ? ? ? ? ? ? ? ? ? ? ? ? (int)tmpu32); >> >> How did a 0x%08x make it into the source after the "2009/04/17 15:44:28" >> change which changed all %p's to host_address_to_string? ?Shouldn't >> this just be a call to host_address_to_string? >> >I am not sure %p or host_address_to_string is right. It is not a >address. Just a simple value. Perusing the gdb source code, I see a fair amount of precedent for using host_address_to_string just to display 0x... >>> ? ? ? ? return 1; >>> ? ? ? } >>> ? ? ? break; >>>@@ -404,7 +404,7 @@ record_linux_system_call (int num, struc >>> ? ? ? /* XXX */ >>> ? ? ? regcache_raw_read (regcache, tdep->arg2, (gdb_byte *) & tmpu32); >>> ? ? sys_fcntl: >>>- ? ? ?if (tmpu32 == F_GETLK) >>>+ ? ? ?if (tmpu32 == tdep->fcntl_F_GETLK) >>> ? ? ? { >>> ? ? ? ? regcache_raw_read (regcache, tdep->arg3, >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ?(gdb_byte *) & tmpu32); >>>@@ -626,7 +626,7 @@ record_linux_system_call (int num, struc >>> ? ? ? ? ? ? ? ? ? "It will free the memory addr = 0x%s len = %d. ?" >>> ? ? ? ? ? ? ? ? ? "It will make record target get error. ?" >>> ? ? ? ? ? ? ? ? ? "Do you want to stop the program?"), >>>- ? ? ? ? ? ? ? ?paddr_nz (tmpu32), len); >>>+ ? ? ? ? ? ? ? ?paddr_nz (tmpu32), (int)len); >> >> If len is a uint32_t isn't casting it to an int the wrong thing to do? >> Looking at the code, len is first defined as uint32_t, then a pointer to >> it is cast as (gdb_byte *) (and it doesn't look like the space following >> the '&' doesn't follow GNU coding standards). ?So it is never actually >> used as a uint32_t. ?That doesn't seem right. >> > >Use uint32_t because it's a 32 bits register's value. So wouldn't that indicate that your format specifier is wrong and should be "%u" rather than "%d"? Coercion is something that should be avoided unless it is absolutely necessary. Also, grepping gdb source code, it seems like other places which use this call use a real gdb_byte to catch it. Either that or they call regcache_raw_read_unsigned. cgf