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

[Hui Zhu <teawater at gmail dot com>]

On Mon, May 11, 2009 at 07:51, Christopher Faylor
<cgf-use-the-mailinglist-please@sourceware.org> wrote:
> 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...

const char *
host_address_to_string (const void *addr)
{
  char *str = get_cell ();

  xsnprintf (str, CELLSIZE, "0x%s", phex_nz ((uintptr_t) addr, sizeof (addr)));
  return str;
}
And code in linux-record.c is for arch target.  So current address
size is not same with 32 bits sometime.
So I use phex_nz directly.

>
>>>> ? ? ? ? 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.
>

I changed it.

> 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.

It will changed to gdb_byte in linux-record.c  64 bits support that I
am working on.

Thanks,
Hui

Attachment: fix-prec-cygwin-build-error.txt
Description: Text document