From: Roland Schwingel <roland@onevision.com>
To: insight@sourceware.org
Subject: [PATCH] Compliancy to windows 64bit
Date: Mon, 19 Mar 2012 12:08:00 -0000 [thread overview]
Message-ID: <4F6721AE.1070406@onevision.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 671 bytes --]
Hi...
On windows 64bit datatype long remains to be 32bit (as opposed to eg.
linux/mac where it is extended to also be 64bit). This yields to some
(easy to fix) problems for insight. The attached patch fixes this.
Changelog:
2012-03-19 Roland Schwingel <roland.schwingel@onevision.com>
* generic/gdbtk-register.c (get_register_types): Cast result of
TYPE_FIELD_TYPE to size_t instead of long.
(gdb_regformat): on windows 64bit use strtoll instead of strtol.
* generic/gdbtk-stack.c (gdb_get_vars_command): Don't cast
clientData to long. Here checking of non NULL clientData is enough.
Any comments? Is this ok?
Roland
[-- Attachment #2: win64_gdbtk-register.c.patch --]
[-- Type: text/plain, Size: 1288 bytes --]
--- gdbtk_orig/generic/gdbtk-register.c 2012-01-03 13:26:56.000000000 +0100
+++ gdbtk/generic/gdbtk-register.c 2012-03-05 12:04:17.458812300 +0100
@@ -240,7 +240,7 @@
{
Tcl_Obj *ar[3], *list;
char *buff;
- buff = xstrprintf ("%lx", (long)TYPE_FIELD_TYPE (reg_vtype, i));
+ buff = xstrprintf ("%lx", (size_t)TYPE_FIELD_TYPE (reg_vtype, i));
ar[0] = Tcl_NewStringObj (TYPE_FIELD_NAME (reg_vtype, i), -1);
ar[1] = Tcl_NewStringObj (buff, -1);
if (TYPE_CODE (TYPE_FIELD_TYPE (reg_vtype, i)) == TYPE_CODE_FLT)
@@ -256,7 +256,7 @@
{
Tcl_Obj *ar[3], *list;
char *buff;
- buff = xstrprintf ("%lx", (long)reg_vtype);
+ buff = xstrprintf ("%lx", (size_t)reg_vtype);
ar[0] = Tcl_NewStringObj (TYPE_NAME(reg_vtype), -1);
ar[1] = Tcl_NewStringObj (buff, -1);
if (TYPE_CODE (reg_vtype) == TYPE_CODE_FLT)
@@ -497,7 +497,11 @@
if (Tcl_GetIntFromObj (interp, objv[0], ®no) != TCL_OK)
return TCL_ERROR;
+ #ifdef _WIN64
+ type = (struct type *)strtoll (Tcl_GetStringFromObj (objv[1], NULL), NULL, 16);
+ #else
type = (struct type *)strtol (Tcl_GetStringFromObj (objv[1], NULL), NULL, 16);
+ #endif
fm = (int)*(Tcl_GetStringFromObj (objv[2], NULL));
numregs = (gdbarch_num_regs (get_current_arch ())
[-- Attachment #3: win64_gdbtk-stack.c.patch --]
[-- Type: text/plain, Size: 327 bytes --]
--- gdbtk_orig/generic/gdbtk-stack.c 2012-03-05 09:19:01.000000000 +0100
+++ gdbtk/generic/gdbtk-stack.c 2012-03-14 11:56:31.851248200 +0100
@@ -289,7 +289,7 @@
return TCL_ERROR;
}
- arguments = (long) clientData;
+ arguments = clientData!=NULL?1:0;
/* Initialize the result pointer to an empty list. */
next reply other threads:[~2012-03-19 12:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-19 12:08 Roland Schwingel [this message]
2012-03-29 22:57 ` Keith Seitz
2012-03-30 7:39 Roland Schwingel
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=4F6721AE.1070406@onevision.com \
--to=roland@onevision.com \
--cc=insight@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).