Re: [Prec/RFA] fix build error of prec in cygwin

[Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org>]

On Mon, May 11, 2009 at 02:07:29AM +0800, Hui Zhu wrote:
>On Mon, May 11, 2009 at 01:48, Christopher Faylor
><cgf-use-the-mailinglist-please@sourceware.org> 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