Re: [RFC/RFA] Allow cygwin native to compile with --enable-64-bit-bfd

[Christopher Faylor <cgf-use-the-mailinglist-please at sourceware dot org>]

On Fri, Nov 23, 2007 at 09:50:27AM +0100, Pierre Muller wrote:
>This patch fixes the build failure for cygwin (or mingw32)
>if you add --enable-64-bit-bfd option to configure.
>
>  When I tried to check the multi-target support
>patch from Ulrich Weigand, I stumpled over a
>win32 native problem.
>See
>  http://sourceware.org/ml/gdb-patches/2007-11/msg00367.html
>
>The problem is that win32-nat.c code implicitly supposes
>the CORE_ADDR is a 32 bit type, while it becomes a
>64 bit type if --enable-64-bit-bfd option is used.
>
>
>  The testsuite gives very similar results
>for gdb configured without options and
>with --enable-64-bit-bfd after that patch.
>
>Pierre Muller
>
>The ChangeLog entry is maybe to verbose, but
>I didn't know how to shorten it.
>
>
>ChangeLog entry:
>
>2007-11-22  Pierre Muller  <muller@ics.u-strasbg.fr>
>
>	*win32-nat.c: Allow compilation if CORE_ADDR is 8 byte long.
>	Add "gdb_stdint.h" dependency required for uintptr_t type use.
>	(handle_output_debug_string): New local variable: addr,
>	used to convert lpDebugStringData pointer to uintptr_t type, which
>can further be
>	typecasted to CORE_ADDR.
>	(handle_exception): Typecast ExceptionAddress field to uintptr_t.
>	(win32_xfer_memory): New local variable: mem_addr,
>	used to convert memaddr of type CORE_ADDR to uintputr_t.
>
>
>
>Index: gdb/win32-nat.c
>===================================================================
>RCS file: /cvs/src/src/gdb/win32-nat.c,v
>retrieving revision 1.139
>diff -u -p -r1.139 win32-nat.c
>--- gdb/win32-nat.c	16 Nov 2007 04:53:46 -0000	1.139
>+++ gdb/win32-nat.c	23 Nov 2007 08:30:33 -0000
>@@ -48,6 +48,7 @@
> #include "objfiles.h"
> #include "gdb_obstack.h"
> #include "gdb_string.h"
>+#include "gdb_stdint.h"
> #include "gdbthread.h"
> #include "gdbcmd.h"
> #include <sys/param.h>
>@@ -818,9 +819,10 @@ handle_output_debug_string (struct targe
> {
>   char *s = NULL;
>   int retval = 0;
>+  uintptr_t addr = (uintptr_t)
>current_event.u.DebugString.lpDebugStringData;
> 
>   if (!target_read_string
>-    ((CORE_ADDR) current_event.u.DebugString.lpDebugStringData, &s, 1024,
>0)
>+    ((CORE_ADDR) addr, &s, 1024, 0)

How can coercing something to uintptr_t and then to CORE_ADDR achieve
anything?  How does the double coercion help?

>       || !s || !*s)
>     /* nothing to do */;
>   else if (strncmp (s, _CYGWIN_SIGNAL_STRING, sizeof
>(_CYGWIN_SIGNAL_STRING) - 1) != 0)
>@@ -1014,7 +1016,7 @@ handle_exception (struct target_waitstat
> 	   and will be sent as a cygwin-specific-signal.  So, ignore SEGVs
>if they show up
> 	   within the text segment of the DLL itself. */
> 	char *fn;
>-	bfd_vma addr = (bfd_vma)
>current_event.u.Exception.ExceptionRecord.ExceptionAddress;
>+	bfd_vma addr = (uintptr_t)
>current_event.u.Exception.ExceptionRecord.ExceptionAddress;

Same question here.  Since you are assigning to a bfd_vma how does the
above help?  Does it avoid a warning or something?

> 	if ((!cygwin_exceptions && (addr >= cygwin_load_start && addr <
>cygwin_load_end))
> 	    || (find_pc_partial_function (addr, &fn, NULL, NULL)
> 		&& strncmp (fn, "KERNEL32!IsBad", strlen ("KERNEL32!IsBad"))
>== 0))
>@@ -1915,20 +1917,22 @@ win32_xfer_memory (CORE_ADDR memaddr, gd
> 		   struct target_ops *target)
> {
>   DWORD done = 0;
>+  uintptr_t mem_addr = (uintptr_t) memaddr;
>+
>   if (write)
>     {
>       DEBUG_MEM (("gdb: write target memory, %d bytes at 0x%08lx\n",
>-		  len, (DWORD) memaddr));
>-      if (!WriteProcessMemory (current_process_handle, (LPVOID) memaddr,
>our,
>+		  len, (DWORD) mem_addr));
>+      if (!WriteProcessMemory (current_process_handle, (LPVOID) mem_addr,
>our,
> 			       len, &done))

Ugh.  Having two variables named "mem_addr" and "memaddr" is a recipe
for confusion.  But, it's the same question: since you're performing a
coercion, why does setting something to a variable earlier in the code
help?

etc.

cgf