From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7252 invoked by alias); 24 Nov 2007 21:07:17 -0000 Received: (qmail 7049 invoked by uid 22791); 24 Nov 2007 21:07:16 -0000 X-Spam-Check-By: sourceware.org Received: from pool-70-20-17-24.bstnma.fios.verizon.net (HELO ednor.cgf.cx) (70.20.17.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 24 Nov 2007 21:07:09 +0000 Received: by ednor.cgf.cx (Postfix, from userid 201) id 302722B352; Sat, 24 Nov 2007 16:07:08 -0500 (EST) Date: Sat, 24 Nov 2007 21:07:00 -0000 From: Christopher Faylor To: gdb-patches@sourceware.org Subject: Re: [RFC/RFA] Allow cygwin native to compile with --enable-64-bit-bfd Message-ID: <20071124210708.GE4928@ednor.casa.cgf.cx> Mail-Followup-To: gdb-patches@sourceware.org References: <000001c82dad$e507e0b0$af17a210$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c82dad$e507e0b0$af17a210$@u-strasbg.fr> User-Agent: Mutt/1.5.16 (2007-06-09) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-11/txt/msg00459.txt.bz2 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 > > *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 >@@ -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