* [PATCH 2/3] Revert "Fix ctrl-c when debugging WOW64 processes"
2020-09-23 17:21 ` [PATCH 1/3] Handle 64bit breakpoints of WOW64 processes as SIGINT Hannes Domani via Gdb-patches
@ 2020-09-23 17:21 ` Hannes Domani via Gdb-patches
2020-09-23 17:21 ` [PATCH 3/3] Remove call of GenerateConsoleCtrlEvent Hannes Domani via Gdb-patches
2020-09-24 3:30 ` [PATCH 1/3] Handle 64bit breakpoints of WOW64 processes as SIGINT Simon Marchi
2 siblings, 0 replies; 14+ messages in thread
From: Hannes Domani via Gdb-patches @ 2020-09-23 17:21 UTC (permalink / raw)
To: gdb-patches
This is no longer needed, since breakpoints in 64bit code can now be
handled by gdb.
2020-09-23 Hannes Domani <ssbssa@yahoo.de>
* windows-nat.c (ctrl_c_handler): Remove special handling for
WOW64 processes.
---
gdb/windows-nat.c | 37 +++----------------------------------
1 file changed, 3 insertions(+), 34 deletions(-)
diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index 1e8e21446f..f9172c3a7f 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -71,7 +71,6 @@
#include "gdbsupport/pathstuff.h"
#include "gdbsupport/gdb_wait.h"
#include "nat/windows-nat.h"
-#include "gdbsupport/symbol.h"
using namespace windows_nat;
@@ -234,9 +233,6 @@ static std::vector<windows_thread_info *> thread_list;
/* Counts of things. */
static int saw_create;
static int open_process_used = 0;
-#ifdef __x86_64__
-static void *wow64_dbgbreak;
-#endif
/* User options. */
static bool new_console = false;
@@ -1523,36 +1519,9 @@ ctrl_c_handler (DWORD event_type)
if (!new_console && !attach_flag)
return TRUE;
-#ifdef __x86_64__
- if (wow64_process)
- {
- /* Call DbgUiRemoteBreakin of the 32bit ntdll.dll in the target process.
- DebugBreakProcess would call the one of the 64bit ntdll.dll, which
- can't be correctly handled by gdb. */
- if (wow64_dbgbreak == nullptr)
- {
- CORE_ADDR addr;
- if (!find_minimal_symbol_address ("ntdll!DbgUiRemoteBreakin",
- &addr, 0))
- wow64_dbgbreak = (void *) addr;
- }
-
- if (wow64_dbgbreak != nullptr)
- {
- HANDLE thread = CreateRemoteThread (current_process_handle, NULL,
- 0, (LPTHREAD_START_ROUTINE)
- wow64_dbgbreak, NULL, 0, NULL);
- if (thread)
- CloseHandle (thread);
- }
- }
- else
-#endif
- {
- if (!DebugBreakProcess (current_process_handle))
- warning (_("Could not interrupt program. "
- "Press Ctrl-c in the program console."));
- }
+ if (!DebugBreakProcess (current_process_handle))
+ warning (_("Could not interrupt program. "
+ "Press Ctrl-c in the program console."));
/* Return true to tell that Ctrl-C has been handled. */
return TRUE;
--
2.27.0
^ permalink raw reply [flat|nested] 14+ messages in thread* [PATCH 3/3] Remove call of GenerateConsoleCtrlEvent
2020-09-23 17:21 ` [PATCH 1/3] Handle 64bit breakpoints of WOW64 processes as SIGINT Hannes Domani via Gdb-patches
2020-09-23 17:21 ` [PATCH 2/3] Revert "Fix ctrl-c when debugging WOW64 processes" Hannes Domani via Gdb-patches
@ 2020-09-23 17:21 ` Hannes Domani via Gdb-patches
2020-09-24 3:35 ` Simon Marchi
2020-09-24 3:30 ` [PATCH 1/3] Handle 64bit breakpoints of WOW64 processes as SIGINT Simon Marchi
2 siblings, 1 reply; 14+ messages in thread
From: Hannes Domani via Gdb-patches @ 2020-09-23 17:21 UTC (permalink / raw)
To: gdb-patches
GenerateConsoleCtrlEvent returns TRUE even if no ctrl-c event was created
in the target process (like if the target doesn't have a console).
Since this prevents DebugBreakProcess from being called (which should
always work), this removes it.
gdbserver/ChangeLog:
2020-09-23 Hannes Domani <ssbssa@yahoo.de>
* win32-low.cc (win32_process_target::request_interrupt):
Remove call of GenerateConsoleCtrlEvent.
---
gdbserver/win32-low.cc | 13 -------------
1 file changed, 13 deletions(-)
diff --git a/gdbserver/win32-low.cc b/gdbserver/win32-low.cc
index 588a23a643..d50fc4c98e 100644
--- a/gdbserver/win32-low.cc
+++ b/gdbserver/win32-low.cc
@@ -101,7 +101,6 @@ const struct target_desc *wow64_win32_tdesc;
typedef BOOL (WINAPI *winapi_DebugActiveProcessStop) (DWORD dwProcessId);
typedef BOOL (WINAPI *winapi_DebugSetProcessKillOnExit) (BOOL KillOnExit);
typedef BOOL (WINAPI *winapi_DebugBreakProcess) (HANDLE);
-typedef BOOL (WINAPI *winapi_GenerateConsoleCtrlEvent) (DWORD, DWORD);
#ifdef __x86_64__
typedef BOOL (WINAPI *winapi_Wow64SetThreadContext) (HANDLE,
@@ -1694,7 +1693,6 @@ void
win32_process_target::request_interrupt ()
{
winapi_DebugBreakProcess DebugBreakProcess;
- winapi_GenerateConsoleCtrlEvent GenerateConsoleCtrlEvent;
#ifdef _WIN32_WCE
HMODULE dll = GetModuleHandle (_T("COREDLL.DLL"));
@@ -1702,17 +1700,6 @@ win32_process_target::request_interrupt ()
HMODULE dll = GetModuleHandle (_T("KERNEL32.DLL"));
#endif
- GenerateConsoleCtrlEvent = GETPROCADDRESS (dll, GenerateConsoleCtrlEvent);
-
- if (GenerateConsoleCtrlEvent != NULL
- && GenerateConsoleCtrlEvent (CTRL_BREAK_EVENT, current_process_id))
- return;
-
- /* GenerateConsoleCtrlEvent can fail if process id being debugged is
- not a process group id.
- Fallback to XP/Vista 'DebugBreakProcess', which generates a
- breakpoint exception in the interior process. */
-
DebugBreakProcess = GETPROCADDRESS (dll, DebugBreakProcess);
if (DebugBreakProcess != NULL
--
2.27.0
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 3/3] Remove call of GenerateConsoleCtrlEvent
2020-09-23 17:21 ` [PATCH 3/3] Remove call of GenerateConsoleCtrlEvent Hannes Domani via Gdb-patches
@ 2020-09-24 3:35 ` Simon Marchi
2020-09-24 14:40 ` Eli Zaretskii via Gdb-patches
0 siblings, 1 reply; 14+ messages in thread
From: Simon Marchi @ 2020-09-24 3:35 UTC (permalink / raw)
To: Hannes Domani, gdb-patches, Eli Zaretskii
On 2020-09-23 1:21 p.m., Hannes Domani via Gdb-patches wrote:
> GenerateConsoleCtrlEvent returns TRUE even if no ctrl-c event was created
> in the target process (like if the target doesn't have a console).
>
> Since this prevents DebugBreakProcess from being called (which should
> always work), this removes it.
Eli, does that make sense to you? Just judging from the explanation
above, it sounds fine to me.
Simon
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 3/3] Remove call of GenerateConsoleCtrlEvent
2020-09-24 3:35 ` Simon Marchi
@ 2020-09-24 14:40 ` Eli Zaretskii via Gdb-patches
2020-09-24 15:01 ` Hannes Domani via Gdb-patches
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii via Gdb-patches @ 2020-09-24 14:40 UTC (permalink / raw)
To: Simon Marchi; +Cc: gdb-patches
> From: Simon Marchi <simark@simark.ca>
> Date: Wed, 23 Sep 2020 23:35:10 -0400
>
> On 2020-09-23 1:21 p.m., Hannes Domani via Gdb-patches wrote:
> > GenerateConsoleCtrlEvent returns TRUE even if no ctrl-c event was created
> > in the target process (like if the target doesn't have a console).
> >
> > Since this prevents DebugBreakProcess from being called (which should
> > always work), this removes it.
>
> Eli, does that make sense to you? Just judging from the explanation
> above, it sounds fine to me.
The explanation sounds fine, but I don't know enough about the
details to say something intelligent. This seems to have some
non-trivial context that I lack to understand, for example, why the
fact that "GenerateConsoleCtrlEvent returns TRUE even if no ctrl-c
event was created in the target process" is a problem.
But it's okay to disregard my ignorance and go ahead with pushing
this.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 3/3] Remove call of GenerateConsoleCtrlEvent
2020-09-24 14:40 ` Eli Zaretskii via Gdb-patches
@ 2020-09-24 15:01 ` Hannes Domani via Gdb-patches
0 siblings, 0 replies; 14+ messages in thread
From: Hannes Domani via Gdb-patches @ 2020-09-24 15:01 UTC (permalink / raw)
To: Simon Marchi, Eli Zaretskii; +Cc: gdb-patches
Am Donnerstag, 24. September 2020, 16:40:27 MESZ hat Eli Zaretskii <eliz@gnu.org> Folgendes geschrieben:
> > From: Simon Marchi <simark@simark.ca>
> > Date: Wed, 23 Sep 2020 23:35:10 -0400
> >
> > On 2020-09-23 1:21 p.m., Hannes Domani via Gdb-patches wrote:
> > > GenerateConsoleCtrlEvent returns TRUE even if no ctrl-c event was created
> > > in the target process (like if the target doesn't have a console).
> > >
> > > Since this prevents DebugBreakProcess from being called (which should
> > > always work), this removes it.
> >
> > Eli, does that make sense to you? Just judging from the explanation
> > above, it sounds fine to me.
>
> The explanation sounds fine, but I don't know enough about the
> details to say something intelligent. This seems to have some
> non-trivial context that I lack to understand, for example, why the
> fact that "GenerateConsoleCtrlEvent returns TRUE even if no ctrl-c
> event was created in the target process" is a problem.
Because then DebugBreakProcess isn't called, and the target process is
not stopped.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/3] Handle 64bit breakpoints of WOW64 processes as SIGINT
2020-09-23 17:21 ` [PATCH 1/3] Handle 64bit breakpoints of WOW64 processes as SIGINT Hannes Domani via Gdb-patches
2020-09-23 17:21 ` [PATCH 2/3] Revert "Fix ctrl-c when debugging WOW64 processes" Hannes Domani via Gdb-patches
2020-09-23 17:21 ` [PATCH 3/3] Remove call of GenerateConsoleCtrlEvent Hannes Domani via Gdb-patches
@ 2020-09-24 3:30 ` Simon Marchi
2020-09-24 15:26 ` Hannes Domani via Gdb-patches
2 siblings, 1 reply; 14+ messages in thread
From: Simon Marchi @ 2020-09-24 3:30 UTC (permalink / raw)
To: Hannes Domani, gdb-patches
On 2020-09-23 1:21 p.m., Hannes Domani via Gdb-patches wrote:
> When a WOW64 process triggers a breakpoint exception in 64bit code (which
> happens when a 64bit gdb calls DebugBreakProcess for a 32bit target),
> gdb ignores the breakpoint (because Wow64GetThreadContext can only report
> the pc of 32bit code, and there is not int3 at this location).
>
> But if these 64bit breakpoint exceptions are handled as SIGINT, gdb
> doesn't check for int3, and always stops the target.
>
> gdb/ChangeLog:
>
> 2020-09-23 Hannes Domani <ssbssa@yahoo.de>
>
> * nat/windows-nat.c (handle_exception): Handle 64bit breakpoints
> in WOW64 processes as SIGINT.
> * nat/windows-nat.h: Make wow64_process a shared variable.
> * windows-nat.c: Remove static wow64_process variable.
>
> gdbserver/ChangeLog:
>
> 2020-09-23 Hannes Domani <ssbssa@yahoo.de>
>
> * win32-low.cc: Remove local wow64_process variable.
> * win32-low.h: Remove local wow64_process variable.
This is ok, but...
> @@ -240,6 +241,13 @@ handle_exception (struct target_waitstatus *ourstatus, bool debug_exceptions)
> 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;
> + }
...please add a comment here saying why this particular handling exists,
it's really not intuitive.
Simon
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 1/3] Handle 64bit breakpoints of WOW64 processes as SIGINT
2020-09-24 3:30 ` [PATCH 1/3] Handle 64bit breakpoints of WOW64 processes as SIGINT Simon Marchi
@ 2020-09-24 15:26 ` Hannes Domani via Gdb-patches
2020-09-24 15:29 ` Simon Marchi
0 siblings, 1 reply; 14+ messages in thread
From: Hannes Domani via Gdb-patches @ 2020-09-24 15:26 UTC (permalink / raw)
To: gdb-patches, Simon Marchi
Am Donnerstag, 24. September 2020, 05:30:11 MESZ hat Simon Marchi <simark@simark.ca> Folgendes geschrieben:
> On 2020-09-23 1:21 p.m., Hannes Domani via Gdb-patches wrote:
> > When a WOW64 process triggers a breakpoint exception in 64bit code (which
> > happens when a 64bit gdb calls DebugBreakProcess for a 32bit target),
> > gdb ignores the breakpoint (because Wow64GetThreadContext can only report
> > the pc of 32bit code, and there is not int3 at this location).
> >
> > But if these 64bit breakpoint exceptions are handled as SIGINT, gdb
> > doesn't check for int3, and always stops the target.
> >
> > gdb/ChangeLog:
> >
> > 2020-09-23 Hannes Domani <ssbssa@yahoo.de>
> >
> > * nat/windows-nat.c (handle_exception): Handle 64bit breakpoints
> > in WOW64 processes as SIGINT.
> > * nat/windows-nat.h: Make wow64_process a shared variable.
> > * windows-nat.c: Remove static wow64_process variable.
> >
> > gdbserver/ChangeLog:
> >
> > 2020-09-23 Hannes Domani <ssbssa@yahoo.de>
> >
> > * win32-low.cc: Remove local wow64_process variable.
> > * win32-low.h: Remove local wow64_process variable.
>
> This is ok, but...
>
>
> > @@ -240,6 +241,13 @@ handle_exception (struct target_waitstatus *ourstatus, bool debug_exceptions)
> > 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;
>
> > + }
>
> ...please add a comment here saying why this particular handling exists,
> it's really not intuitive.
Is it ok with this addition?:
diff --git a/gdb/nat/windows-nat.c b/gdb/nat/windows-nat.c
index a277156138..2cbbc0f2cc 100644
--- a/gdb/nat/windows-nat.c
+++ b/gdb/nat/windows-nat.c
@@ -243,6 +243,13 @@ handle_exception (struct target_waitstatus *ourstatus, bool debug_exceptions)
}
else if (wow64_process)
{
+ /* This breakpoint exception is triggered for WOW64 processes when
+ reaching an int3 instruction in 64bit code.
+ gdb checks for int3 in case of SIGTRAP, this fails because
+ Wow64GetThreadContext can only report the pc of 32bit code, and
+ gdb lets the target process continue.
+ So handle it as SIGINT instead, then the target is stopped
+ unconditionally. */
DEBUG_EXCEPTION_SIMPLE ("EXCEPTION_BREAKPOINT");
rec->ExceptionCode = DBG_CONTROL_C;
ourstatus->value.sig = GDB_SIGNAL_INT;
Hannes
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 1/3] Handle 64bit breakpoints of WOW64 processes as SIGINT
2020-09-24 15:26 ` Hannes Domani via Gdb-patches
@ 2020-09-24 15:29 ` Simon Marchi
2020-09-24 16:37 ` Hannes Domani via Gdb-patches
0 siblings, 1 reply; 14+ messages in thread
From: Simon Marchi @ 2020-09-24 15:29 UTC (permalink / raw)
To: Hannes Domani, gdb-patches
On 2020-09-24 11:26 a.m., Hannes Domani wrote:
> Is it ok with this addition?:
>
> diff --git a/gdb/nat/windows-nat.c b/gdb/nat/windows-nat.c
> index a277156138..2cbbc0f2cc 100644
> --- a/gdb/nat/windows-nat.c
> +++ b/gdb/nat/windows-nat.c
> @@ -243,6 +243,13 @@ handle_exception (struct target_waitstatus *ourstatus, bool debug_exceptions)
> }
> else if (wow64_process)
> {
> + /* This breakpoint exception is triggered for WOW64 processes when
> + reaching an int3 instruction in 64bit code.
> + gdb checks for int3 in case of SIGTRAP, this fails because
> + Wow64GetThreadContext can only report the pc of 32bit code, and
> + gdb lets the target process continue.
> + So handle it as SIGINT instead, then the target is stopped
> + unconditionally. */
> DEBUG_EXCEPTION_SIMPLE ("EXCEPTION_BREAKPOINT");
> rec->ExceptionCode = DBG_CONTROL_C;
> ourstatus->value.sig = GDB_SIGNAL_INT;
That is fine with me, thanks.
Just to make sure I understand, stopping a 32-bit process from a 64-bit
GDB is the only time we expect this to happen, right?
Simon
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 1/3] Handle 64bit breakpoints of WOW64 processes as SIGINT
2020-09-24 15:29 ` Simon Marchi
@ 2020-09-24 16:37 ` Hannes Domani via Gdb-patches
2020-09-24 16:42 ` Simon Marchi
0 siblings, 1 reply; 14+ messages in thread
From: Hannes Domani via Gdb-patches @ 2020-09-24 16:37 UTC (permalink / raw)
To: gdb-patches, Simon Marchi
Am Donnerstag, 24. September 2020, 17:29:50 MESZ hat Simon Marchi <simark@simark.ca> Folgendes geschrieben:
> On 2020-09-24 11:26 a.m., Hannes Domani wrote:
> > Is it ok with this addition?:
> >
> > diff --git a/gdb/nat/windows-nat.c b/gdb/nat/windows-nat.c
> > index a277156138..2cbbc0f2cc 100644
> > --- a/gdb/nat/windows-nat.c
> > +++ b/gdb/nat/windows-nat.c
> > @@ -243,6 +243,13 @@ handle_exception (struct target_waitstatus *ourstatus, bool debug_exceptions)
> > }
> > else if (wow64_process)
> > {
> > + /* This breakpoint exception is triggered for WOW64 processes when
> > + reaching an int3 instruction in 64bit code.
> > + gdb checks for int3 in case of SIGTRAP, this fails because
> > + Wow64GetThreadContext can only report the pc of 32bit code, and
> > + gdb lets the target process continue.
> > + So handle it as SIGINT instead, then the target is stopped
> > + unconditionally. */
> > DEBUG_EXCEPTION_SIMPLE ("EXCEPTION_BREAKPOINT");
> > rec->ExceptionCode = DBG_CONTROL_C;
> > ourstatus->value.sig = GDB_SIGNAL_INT;
>
> That is fine with me, thanks.
>
> Just to make sure I understand, stopping a 32-bit process from a 64-bit
> GDB is the only time we expect this to happen, right?
Yes.
Hannes
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 1/3] Handle 64bit breakpoints of WOW64 processes as SIGINT
2020-09-24 16:37 ` Hannes Domani via Gdb-patches
@ 2020-09-24 16:42 ` Simon Marchi
2020-09-24 17:05 ` Hannes Domani via Gdb-patches
0 siblings, 1 reply; 14+ messages in thread
From: Simon Marchi @ 2020-09-24 16:42 UTC (permalink / raw)
To: Hannes Domani, gdb-patches
On 2020-09-24 12:37 p.m., Hannes Domani via Gdb-patches wrote:
> Am Donnerstag, 24. September 2020, 17:29:50 MESZ hat Simon Marchi <simark@simark.ca> Folgendes geschrieben:
>
>> On 2020-09-24 11:26 a.m., Hannes Domani wrote:
>>> Is it ok with this addition?:
>>>
>>> diff --git a/gdb/nat/windows-nat.c b/gdb/nat/windows-nat.c
>>> index a277156138..2cbbc0f2cc 100644
>>> --- a/gdb/nat/windows-nat.c
>>> +++ b/gdb/nat/windows-nat.c
>>> @@ -243,6 +243,13 @@ handle_exception (struct target_waitstatus *ourstatus, bool debug_exceptions)
>>> }
>>> else if (wow64_process)
>>> {
>>> + /* This breakpoint exception is triggered for WOW64 processes when
>>> + reaching an int3 instruction in 64bit code.
>>> + gdb checks for int3 in case of SIGTRAP, this fails because
>>> + Wow64GetThreadContext can only report the pc of 32bit code, and
>>> + gdb lets the target process continue.
>>> + So handle it as SIGINT instead, then the target is stopped
>>> + unconditionally. */
>>> DEBUG_EXCEPTION_SIMPLE ("EXCEPTION_BREAKPOINT");
>>> rec->ExceptionCode = DBG_CONTROL_C;
>>> ourstatus->value.sig = GDB_SIGNAL_INT;
>>
>> That is fine with me, thanks.
>>
>> Just to make sure I understand, stopping a 32-bit process from a 64-bit
>> GDB is the only time we expect this to happen, right?
Ok, thanks. Please go ahead and merge.
Simon
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 1/3] Handle 64bit breakpoints of WOW64 processes as SIGINT
2020-09-24 16:42 ` Simon Marchi
@ 2020-09-24 17:05 ` Hannes Domani via Gdb-patches
2020-09-24 17:22 ` Joel Brobecker
0 siblings, 1 reply; 14+ messages in thread
From: Hannes Domani via Gdb-patches @ 2020-09-24 17:05 UTC (permalink / raw)
To: gdb-patches, Simon Marchi, Joel Brobecker
Am Donnerstag, 24. September 2020, 18:42:33 MESZ hat Simon Marchi <simark@simark.ca> Folgendes geschrieben:
> On 2020-09-24 12:37 p.m., Hannes Domani via Gdb-patches wrote:
> > Am Donnerstag, 24. September 2020, 17:29:50 MESZ hat Simon Marchi <simark@simark.ca> Folgendes geschrieben:
> >
> >> On 2020-09-24 11:26 a.m., Hannes Domani wrote:
> >>> Is it ok with this addition?:
> >>>
> >>> diff --git a/gdb/nat/windows-nat.c b/gdb/nat/windows-nat.c
> >>> index a277156138..2cbbc0f2cc 100644
> >>> --- a/gdb/nat/windows-nat.c
> >>> +++ b/gdb/nat/windows-nat.c
> >>> @@ -243,6 +243,13 @@ handle_exception (struct target_waitstatus *ourstatus, bool debug_exceptions)
> >>> }
> >>> else if (wow64_process)
> >>> {
> >>> + /* This breakpoint exception is triggered for WOW64 processes when
> >>> + reaching an int3 instruction in 64bit code.
> >>> + gdb checks for int3 in case of SIGTRAP, this fails because
> >>> + Wow64GetThreadContext can only report the pc of 32bit code, and
> >>> + gdb lets the target process continue.
> >>> + So handle it as SIGINT instead, then the target is stopped
> >>> + unconditionally. */
> >>> DEBUG_EXCEPTION_SIMPLE ("EXCEPTION_BREAKPOINT");
> >>> rec->ExceptionCode = DBG_CONTROL_C;
> >>> ourstatus->value.sig = GDB_SIGNAL_INT;
> >>
> >> That is fine with me, thanks.
> >>
> >> Just to make sure I understand, stopping a 32-bit process from a 64-bit
> >> GDB is the only time we expect this to happen, right?
>
> Ok, thanks. Please go ahead and merge.
Pushed, thanks.
I think it would be great to have this in the gdb-10-branch.
Would that be possible?
Hannes
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 1/3] Handle 64bit breakpoints of WOW64 processes as SIGINT
2020-09-24 17:05 ` Hannes Domani via Gdb-patches
@ 2020-09-24 17:22 ` Joel Brobecker
2020-09-24 17:51 ` Hannes Domani via Gdb-patches
0 siblings, 1 reply; 14+ messages in thread
From: Joel Brobecker @ 2020-09-24 17:22 UTC (permalink / raw)
To: Hannes Domani; +Cc: Simon Marchi, gdb-patches
> > >>> diff --git a/gdb/nat/windows-nat.c b/gdb/nat/windows-nat.c
> > >>> index a277156138..2cbbc0f2cc 100644
> > >>> --- a/gdb/nat/windows-nat.c
> > >>> +++ b/gdb/nat/windows-nat.c
> > >>> @@ -243,6 +243,13 @@ handle_exception (struct target_waitstatus *ourstatus, bool debug_exceptions)
> > >>> }
> > >>> else if (wow64_process)
> > >>> {
> > >>> + /* This breakpoint exception is triggered for WOW64 processes when
> > >>> + reaching an int3 instruction in 64bit code.
> > >>> + gdb checks for int3 in case of SIGTRAP, this fails because
> > >>> + Wow64GetThreadContext can only report the pc of 32bit code, and
> > >>> + gdb lets the target process continue.
> > >>> + So handle it as SIGINT instead, then the target is stopped
> > >>> + unconditionally. */
> > >>> DEBUG_EXCEPTION_SIMPLE ("EXCEPTION_BREAKPOINT");
> > >>> rec->ExceptionCode = DBG_CONTROL_C;
> > >>> ourstatus->value.sig = GDB_SIGNAL_INT;
> > >>
> > >> That is fine with me, thanks.
> > >>
> > >> Just to make sure I understand, stopping a 32-bit process from a 64-bit
> > >> GDB is the only time we expect this to happen, right?
> >
> > Ok, thanks. Please go ahead and merge.
>
> Pushed, thanks.
>
> I think it would be great to have this in the gdb-10-branch.
> Would that be possible?
OK for me, Hannes.
--
Joel
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 1/3] Handle 64bit breakpoints of WOW64 processes as SIGINT
2020-09-24 17:22 ` Joel Brobecker
@ 2020-09-24 17:51 ` Hannes Domani via Gdb-patches
0 siblings, 0 replies; 14+ messages in thread
From: Hannes Domani via Gdb-patches @ 2020-09-24 17:51 UTC (permalink / raw)
To: Joel Brobecker; +Cc: Simon Marchi, gdb-patches
Am Donnerstag, 24. September 2020, 19:22:51 MESZ hat Joel Brobecker <brobecker@adacore.com> Folgendes geschrieben:
> > > >>> diff --git a/gdb/nat/windows-nat.c b/gdb/nat/windows-nat.c
> > > >>> index a277156138..2cbbc0f2cc 100644
> > > >>> --- a/gdb/nat/windows-nat.c
> > > >>> +++ b/gdb/nat/windows-nat.c
> > > >>> @@ -243,6 +243,13 @@ handle_exception (struct target_waitstatus *ourstatus, bool debug_exceptions)
> > > >>> }
> > > >>> else if (wow64_process)
> > > >>> {
> > > >>> + /* This breakpoint exception is triggered for WOW64 processes when
> > > >>> + reaching an int3 instruction in 64bit code.
> > > >>> + gdb checks for int3 in case of SIGTRAP, this fails because
> > > >>> + Wow64GetThreadContext can only report the pc of 32bit code, and
> > > >>> + gdb lets the target process continue.
> > > >>> + So handle it as SIGINT instead, then the target is stopped
> > > >>> + unconditionally. */
> > > >>> DEBUG_EXCEPTION_SIMPLE ("EXCEPTION_BREAKPOINT");
> > > >>> rec->ExceptionCode = DBG_CONTROL_C;
> > > >>> ourstatus->value.sig = GDB_SIGNAL_INT;
> > > >>
> > > >> That is fine with me, thanks.
> > > >>
> > > >> Just to make sure I understand, stopping a 32-bit process from a 64-bit
> > > >> GDB is the only time we expect this to happen, right?
> > >
> > > Ok, thanks. Please go ahead and merge.
> >
> > Pushed, thanks.
> >
> > I think it would be great to have this in the gdb-10-branch.
> > Would that be possible?
>
>
> OK for me, Hannes.
Thanks, pushed as well to gdb-10-branch.
Hannes
^ permalink raw reply [flat|nested] 14+ messages in thread