Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Hui Zhu <teawater@gmail.com>
To: Hui Zhu <teawater@gmail.com>, gdb-patches@sourceware.org
Subject: Re: [Prec/RFA] fix build error of prec in cygwin
Date: Sun, 10 May 2009 18:07:00 -0000	[thread overview]
Message-ID: <daef60380905101107u25e55c38jaf05c7977adf57b6@mail.gmail.com> (raw)
In-Reply-To: <20090510174809.GA25909@ednor.casa.cgf.cx>

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.

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

>>       target_terminal_inferior ();
>>       if (q)
>>         return 1;
>>@@ -935,7 +935,7 @@ record_linux_system_call (int num, struc
>>       default:
>>         printf_unfiltered (_("Process record and replay target "
>>                              "doesn't support socketcall call 0x%08x\n"),
>>-                           tmpu32);
>>+                           (int)tmpu32);
>
> Same observation.  This cast seems wrong.
>
>>         return -1;
>>         break;
>>       }
>>@@ -1631,20 +1631,17 @@ record_linux_system_call (int num, struc
>>       /* sys_fcntl64 */
>>     case 221:
>>       regcache_raw_read (regcache, tdep->arg2, (gdb_byte *) & tmpu32);
>>-      switch (tmpu32)
>>-      {
>>-      case F_GETLK64:
>>+      if (tmpu32 == tdep->fcntl_F_GETLK64)
>>+        {
>>         regcache_raw_read (regcache, tdep->arg3,
>>                            (gdb_byte *) & tmpu32);
>>         if (record_arch_list_add_mem (tmpu32, tdep->size_flock64))
>>           return -1;
>>-        break;
>>-      case F_SETLK64:
>>-      case F_SETLKW64:
>>-        break;
>>-      default:
>>+      }
>>+      else if (tmpu32 != tdep->fcntl_F_SETLK64
>>+             && tmpu32 != tdep->fcntl_F_SETLKW64)
>>+        {
>>         goto sys_fcntl;
>>-        break;
>>       }
>>       break;
>>
>>@@ -1786,7 +1783,8 @@ record_linux_system_call (int num, struc
>>               fprintf_unfiltered (gdb_stdlog,
>>                                   "Process record: error reading memory "
>>                                   "at addr = 0x%s len = %d.\n",
>>-                                  paddr_nz (tmpu32), nr * tdep->size_int);
>>+                                  paddr_nz (tmpu32),
>>+                                  (int)(nr * tdep->size_int));
>
> ...and so on...
>>             return -1;
>>           }
>>         for (i = 0; i < nr; i++)
>>@@ -2196,7 +2194,7 @@ record_linux_system_call (int num, struc
>>     default:
>>       printf_unfiltered (_("Process record and replay target doesn't "
>>                          "support syscall number 0x%08x\n"),
>>-                       tmpu32);
>>+                       (int)tmpu32);
>
> ...and so on...
>


  reply	other threads:[~2009-05-10 18:07 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-10 17:31 Hui Zhu
2009-05-10 17:48 ` Christopher Faylor
2009-05-10 18:07   ` Hui Zhu [this message]
2009-05-10 23:51     ` Christopher Faylor
2009-05-18  8:43       ` Hui Zhu
2009-05-18 15:35         ` Christopher Faylor
2009-05-19  2:34           ` Hui Zhu
2009-05-21  2:39             ` Hui Zhu
2009-05-21 15:26               ` Christopher Faylor
2009-05-21 15:35                 ` Pedro Alves
2009-05-21 17:35                   ` Christopher Faylor
2009-05-21 16:43                 ` Hui Zhu
2009-05-21 17:38                   ` Christopher Faylor
2009-05-21 23:14                     ` Hui Zhu
2009-05-22  0:46                       ` Christopher Faylor
2009-05-22  2:12                         ` Hui Zhu
2009-05-22  4:13                           ` Christopher Faylor
2009-05-22  5:53                             ` Hui Zhu
2009-05-22  6:05                             ` Joel Brobecker
2009-05-22  6:56                               ` Eli Zaretskii
2009-05-22  8:42                                 ` Hui Zhu
2009-05-22  9:37                                   ` Eli Zaretskii
2009-05-22 10:11                                   ` Jie Zhang
2009-05-22  9:06                                 ` Hui Zhu
2009-05-22  9:30                                   ` Eli Zaretskii
2009-05-22 14:11                                     ` Hui Zhu
2009-05-22 17:02                               ` Christopher Faylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=daef60380905101107u25e55c38jaf05c7977adf57b6@mail.gmail.com \
    --to=teawater@gmail.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox