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

Christopher Faylor
2007-11-24T21:07:17Z

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