* [PATCH] Compliancy to windows 64bit
@ 2012-03-19 12:08 Roland Schwingel
2012-03-29 22:57 ` Keith Seitz
0 siblings, 1 reply; 3+ messages in thread
From: Roland Schwingel @ 2012-03-19 12:08 UTC (permalink / raw)
To: insight
[-- 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. */
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] Compliancy to windows 64bit
2012-03-19 12:08 [PATCH] Compliancy to windows 64bit Roland Schwingel
@ 2012-03-29 22:57 ` Keith Seitz
0 siblings, 0 replies; 3+ messages in thread
From: Keith Seitz @ 2012-03-29 22:57 UTC (permalink / raw)
To: Roland Schwingel; +Cc: insight
On 03/19/2012 05:08 AM, Roland Schwingel wrote:
> Any comments? Is this ok?
Wow, I had no idea we were harboring such evil code... Passing host
pointers into the interpreter and back again. Eeeew! [Alas, this portion
of insight is probably about the oldest...] This whole thing should have
been done some other way. [But that's probably not the comment you're
attempting to elicit. :-)]
Just a nit:
> --- 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. */
>
This isn't formatted properly. It should be:
arguments = clientData != NULL ? 1 : 0;
Okay with that change.
Keith
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] Compliancy to windows 64bit
@ 2012-03-30 7:39 Roland Schwingel
0 siblings, 0 replies; 3+ messages in thread
From: Roland Schwingel @ 2012-03-30 7:39 UTC (permalink / raw)
To: Keith Seitz, insight
Hi...
Keith Seitz <keiths@redhat.com> wrote on 30.03.2012 00:56:53:
> Wow, I had no idea we were harboring such evil code... Passing host
> pointers into the interpreter and back again. Eeeew! [Alas, this portion
> of insight is probably about the oldest...] This whole thing should have
> been done some other way. [But that's probably not the comment you're
> attempting to elicit. :-)]
;-)
> Just a nit:
> > - arguments = (long) clientData;
> > + arguments = clientData!=NULL?1:0;
> This isn't formatted properly. It should be:
>
> arguments = clientData != NULL ? 1 : 0;
Fixed that on commit.
> Okay with that change.
I also updated copyright years in the 2 files touched by my changes and
mentioned that in Changelog.
Roland
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-03-30 7:39 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-03-19 12:08 [PATCH] Compliancy to windows 64bit Roland Schwingel
2012-03-29 22:57 ` Keith Seitz
2012-03-30 7:39 Roland Schwingel
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).