Re: [PATCH] Fix ctrl-c when debugging WOW64 processes

[Hannes Domani <ssbssa@yahoo.de>]

 Am Donnerstag, 17. September 2020, 22:56:45 MESZ hat Hannes Domani via Gdb-patches <gdb-patches@sourceware.org> Folgendes geschrieben:

> Am Donnerstag, 17. September 2020, 22:18:01 MESZ hat Tom Tromey <tom@tromey.com> Folgendes geschrieben:
>
> > >>>>> "Hannes" == Hannes Domani via Gdb-patches <gdb-patches@sourceware.org> writes:
> >
> > Hannes> 2020-09-17  Hannes Domani  <ssbssa@yahoo.de>
> >
> > Hannes>     * windows-nat.c (ctrl_c_handler): Use 32bit DbgUiRemoteBreakin
> > Hannes>     for WOW64 processes.
> >
> > Does gdbserver need this treatment as well?
> > If so maybe this code can be shared.
>
> I thought so, but I just tried it and it works without it.
>
> The reason seems to be that gdbserver first calls GenerateConsoleCtrlEvent(),
> and only when that fails falls back to DebugBreakProcess().
>
> When I tried to do the same in gdb just now, it didn't work.
> Weird, I will have to investigate this some more.

I did some experiments.

Seems like GenerateConsoleCtrlEvent() only works if the target process was
created without CREATE_NEW_CONSOLE.
And what's worse, it seems to always return TRUE, so it never reaches
DebugBreakProcess(), even if the target process doesn't have a console at all.

I also tried the "last resort", with soft_interrupt_requested=1, but this
immediatly crashed gdbserver.

I fixed this crash with:

--- a/gdbserver/win32-low.cc
+++ b/gdbserver/win32-low.cc
@@ -1339,6 +1335,7 @@ fake_breakpoint_event (void)
   faked_breakpoint = 1;

   memset (&current_event, 0, sizeof (current_event));
+  current_event.dwProcessId = current_process_id;
   current_event.dwThreadId = main_thread_id;
   current_event.dwDebugEventCode = EXCEPTION_DEBUG_EVENT;
   current_event.u.Exception.ExceptionRecord.ExceptionCode

But this didn't work either, I think it's because gdb checks if the current
instruction is int3, and continues if not.

I'm wondering why this last resort was added, was this done for pre-XP where
DebugBreakProcess() didn't exist?

So right now ctrl-c doesn't really work that well with gdbserver, and not
at all when debugging a program without console (WOW64 or not doesn't matter).


And the WOW64 fix for DbgUiRemoteBreakin() probably can't be used in
gdbserver, because find_minimal_symbol_address() is not available.


Meanwhile I came up with a possible alternative for DbgUiRemoteBreakin():

--- a/gdb/nat/windows-nat.c
+++ b/gdb/nat/windows-nat.c
@@ -240,6 +241,13 @@ handle_exception (struct target_waitstatus *ourstatus, bool debug_exceptions)
     case EXCEPTION_BREAKPOINT:
 #ifdef __x86_64__
       if (ignore_first_breakpoint)
     {
       /* For WOW64 processes, there are always 2 breakpoint exceptions
          on startup, first a BREAKPOINT for the 64bit ntdll.dll,
          then a WX86_BREAKPOINT for the 32bit ntdll.dll.
          Here we only care about the WX86_BREAKPOINT's.  */
           ourstatus->kind = TARGET_WAITKIND_SPURIOUS;
          ignore_first_breakpoint = false;
        }
+      else if (wow64_process)
+       {
+         DEBUG_EXCEPTION_SIMPLE ("EXCEPTION_BREAKPOINT");
+         rec->ExceptionCode = DBG_CONTROL_C;
+         ourstatus->value.sig = GDB_SIGNAL_INT;
+         break;
+       }
 #endif
       /* FALLTHROUGH */
     case STATUS_WX86_BREAKPOINT:

This transforms the (64bit) breakpoint from DebugBreakProcess() into
SIGINT, then the check for the int3 instruction is not done, and gdb stops
the target process in any case.

So far this seems to work fine for both gdb and gdbserver.


Hannes