This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]