This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] [1/4] Mingw64 gdbserver support
- From: Pedro Alves <pedro at codesourcery dot com>
- To: "Pierre Muller" <pierre dot muller at ics-cnrs dot unistra dot fr>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 20 Apr 2010 00:14:29 +0100
- Subject: Re: [RFA] [1/4] Mingw64 gdbserver support
- References: <000f01cae013$79556340$6c0029c0$@muller@ics-cnrs.unistra.fr>
On Monday 19 April 2010 23:55:57, Pierre Muller wrote:
> It would be nice if someone could check that this
> patch works for mingwce targets, I cannot do this myself.
Don't worry about it. I'll do that after the patch is applied, if
noone beats me to it. It may take me a while, but I'll surely test
on CE before the next release.
> gdbserver ChangeLog entry:
>
> 2010-04-19 Pierre Muller <muller@ics.u-strasbg.fr>
>
> * win32-low.c: Adapt to support also 64-bit architecture.
> (child_xfer_memory): Use uintptr_t type for local variable `addr'.
> (get_image_name): Use SIZE_T type for local variable `done'.
> (psapi_get_dll_name): Use uintptr_t type for parameter
> `BaseAddress'.
> (toolhelp_get_dll_name): Idem.
> (handle_load_dll): Use uintptr_t type for local variable
> `load_addr'.
> (handle_unload_dll): Use unitptr_t typecast to avoid warning.
Typo: unitptr_t.
> (handle_exception): Use phex_nz to avoid warning.
> (win32_wait): Remove unused local variable `process'.
>
> Index: gdbserver/win32-low.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/gdbserver/win32-low.c,v
> retrieving revision 1.46
> diff -u -p -r1.46 win32-low.c
> --- gdbserver/win32-low.c 16 Apr 2010 07:49:37 -0000 1.46
> +++ gdbserver/win32-low.c 17 Apr 2010 22:08:36 -0000
> @@ -280,7 +280,7 @@ child_xfer_memory (CORE_ADDR memaddr, ch
> int write, struct target_ops *target)
> {
> SIZE_T done;
> - long addr = (long) memaddr;
> + uintptr_t addr = (uintptr_t) memaddr;
>
> if (write)
> {
> @@ -941,7 +941,7 @@ get_image_name (HANDLE h, void *address,
> char *address_ptr;
> int len = 0;
> char b[2];
> - DWORD done;
> + SIZE_T done;
>
> /* Attempt to read the name of the dll that was detected.
> This is documented to work only when actively debugging
> @@ -1019,7 +1019,7 @@ load_psapi (void)
> }
>
> static int
> -psapi_get_dll_name (DWORD BaseAddress, char *dll_name_ret)
> +psapi_get_dll_name (uintptr_t BaseAddress, char *dll_name_ret)
Make this one above,
> @@ -1134,7 +1134,7 @@ load_toolhelp (void)
> }
>
> static int
> -toolhelp_get_dll_name (DWORD BaseAddress, char *dll_name_ret)
> +toolhelp_get_dll_name (uintptr_t BaseAddress, char *dll_name_ret)
and this one, take an LPVOID/void* instead, like the
equivalent gdb/windows-nat.c code, and most of the casts
disappear. Again, please remember that gdb/windows-nat.c has all
these problems fixed already. Remember to take a look there..
> {
> HANDLE snapshot_module;
> MODULEENTRY32 modEntry = { sizeof (MODULEENTRY32) };
> @@ -1151,7 +1151,7 @@ toolhelp_get_dll_name (DWORD BaseAddress
> /* Ignore the first module, which is the exe. */
> if (win32_Module32First (snapshot_module, &modEntry))
> while (win32_Module32Next (snapshot_module, &modEntry))
> - if ((DWORD) modEntry.modBaseAddr == BaseAddress)
> + if ((uintptr_t) modEntry.modBaseAddr == BaseAddress)
... like this one...
> {
> #ifdef UNICODE
> wcstombs (dll_name_ret, modEntry.szExePath, MAX_PATH + 1);
> @@ -1176,21 +1176,21 @@ handle_load_dll (void)
> LOAD_DLL_DEBUG_INFO *event = ¤t_event.u.LoadDll;
> char dll_buf[MAX_PATH + 1];
> char *dll_name = NULL;
> - DWORD load_addr;
> + uintptr_t load_addr;
>
> dll_buf[0] = dll_buf[sizeof (dll_buf) - 1] = '\0';
>
> /* Windows does not report the image name of the dlls in the debug
> event on attaches. We resort to iterating over the list of
> loaded dlls looking for a match by image base. */
> - if (!psapi_get_dll_name ((DWORD) event->lpBaseOfDll, dll_buf))
> + if (!psapi_get_dll_name ((uintptr_t) event->lpBaseOfDll, dll_buf))
and this one...
> {
> if (!server_waiting)
> /* On some versions of Windows and Windows CE, we can't create
> toolhelp snapshots while the inferior is stopped in a
> LOAD_DLL_DEBUG_EVENT due to a dll load, but we can while
> Windows is reporting the already loaded dlls. */
> - toolhelp_get_dll_name ((DWORD) event->lpBaseOfDll, dll_buf);
> + toolhelp_get_dll_name ((uintptr_t) event->lpBaseOfDll, dll_buf);
and this one.
> }
>
> dll_name = dll_buf;
> @@ -1205,7 +1205,7 @@ handle_load_dll (void)
> the offset from 0 of the first byte in an image - because
> of the file header and the section alignment. */
>
> - load_addr = (DWORD) event->lpBaseOfDll + 0x1000;
> + load_addr = (uintptr_t) event->lpBaseOfDll + 0x1000;
> win32_add_one_solib (dll_name, load_addr);
> }
>
> @@ -1213,7 +1213,7 @@ static void
> handle_unload_dll (void)
> {
> CORE_ADDR load_addr =
> - (CORE_ADDR) (DWORD) current_event.u.UnloadDll.lpBaseOfDll;
> + (CORE_ADDR) (uintptr_t) current_event.u.UnloadDll.lpBaseOfDll;
> load_addr += 0x1000;
> unloaded_dll (NULL, load_addr);
> }
> @@ -1314,10 +1314,10 @@ handle_exception (struct target_waitstat
> ourstatus->kind = TARGET_WAITKIND_SPURIOUS;
> return;
> }
> - OUTMSG2 (("gdbserver: unknown target exception 0x%08lx at 0x%08lx",
> + OUTMSG2 (("gdbserver: unknown target exception 0x%08lx at 0x%s",
> current_event.u.Exception.ExceptionRecord.ExceptionCode,
> - (DWORD) current_event.u.Exception.ExceptionRecord.
> - ExceptionAddress));
> + phex_nz ((uintptr_t)
> current_event.u.Exception.ExceptionRecord.
> + ExceptionAddress, sizeof(uintptr_t))));
Missing space before parens.
> ourstatus->value.sig = TARGET_SIGNAL_UNKNOWN;
> break;
> }
> @@ -1577,7 +1577,6 @@ get_child_debug_event (struct target_wai
> static ptid_t
> win32_wait (ptid_t ptid, struct target_waitstatus *ourstatus, int options)
> {
> - struct process_info *process;
> struct regcache *regcache;
>
> while (1)
>
--
Pedro Alves