Re: [PATCH 7/7] Reset Windows hardware breakpoints on executable's entry point

[Hannes Domani <ssbssa@yahoo.de>]

 Am Mittwoch, 27. Mai 2020, 16:48:16 MESZ hat Pedro Alves <palves@redhat.com> Folgendes geschrieben:

> On 5/27/20 1:07 PM, Pedro Alves via Gdb-patches wrote:
> > On 5/25/20 7:56 PM, Hannes Domani via Gdb-patches wrote:
> >> Fixes these testsuite fails on Windows (actually more, but the others are
> >> cascading failures):
> >> FAIL: gdb.base/hbreak2.exp: hardware breakpoint insertion (the program exited)
> >> FAIL: gdb.base/hbreak2.exp: run until function breakpoint (the program exited)
> >> FAIL: gdb.base/hbreak2.exp: run to factorial(6) (the program exited)
> >> FAIL: gdb.base/hbreak2.exp: run until hardware function breakpoint, optimized file (the program exited)
> >>
> >> The problem happens if you only have hardware breakpoints active when
> >> (re-)starting the program:
> >>
> >> (gdb) start
> >> Temporary breakpoint 1 at 0x401650: file C:/src/repos/binutils-gdb.git/gdb/tests
> >> uite/gdb.base/break.c, line 43.
> >> Starting program: C:\gdb\build64\gdb-git\gdb\testsuite\outputs\gdb.base\hbreak2\
> >> hbreak2.exe
> >>
> >> Temporary breakpoint 1, main (argc=1, argv=0x7e2120, envp=0x7e2900)
> >>    at C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.base/break.c:43
> >> 43          if (argc == 12345) {  /* an unlikely value < 2^16, in case uninited
> >> */ /* set breakpoint 6 here */
> >> (gdb) hb factorial
> >> Hardware assisted breakpoint 2 at 0x401703: file C:/src/repos/binutils-gdb.git/g
> >> db/testsuite/gdb.base/break.c, line 63.
> >> (gdb) r
> >> The program being debugged has been started already.
> >> Start it from the beginning? (y or n) y
> >> Starting program: C:\gdb\build64\gdb-git\gdb\testsuite\outputs\gdb.base\hbreak2\
> >> hbreak2.exe
> >> 720
> >> [Inferior 1 (process 7836) exited normally]
> >>
> >> But if you stopped just once before reaching the hardware breakpoint, it
> >> works fine:
> >>
> >> (gdb) start
> >> Temporary breakpoint 3 at 0x401650: file C:/src/repos/binutils-gdb.git/gdb/tests
> >> uite/gdb.base/break.c, line 43.
> >> Starting program: C:\gdb\build64\gdb-git\gdb\testsuite\outputs\gdb.base\hbreak2\
> >> hbreak2.exe
> >>
> >> Temporary breakpoint 3, main (argc=1, argv=0x322120, envp=0x322900)
> >>    at C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.base/break.c:43
> >> 43          if (argc == 12345) {  /* an unlikely value < 2^16, in case uninited
> >> */ /* set breakpoint 6 here */
> >> (gdb) c
> >> Continuing.
> >>
> >> Breakpoint 2, factorial (value=6)
> >>    at C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.base/break.c:63
> >> 63        if (value > 1) {  /* set breakpoint 7 here */
> >>
> >> I found out that cdb writes this error when trying to do the same:
> >>
> >> Unable to set breakpoint error
> >> The system resets thread contexts after the process
> >> breakpoint so hardware breakpoints cannot be set.
> >> Go to the executable's entry point and set it then.
> >>
> >> So all the hardware breakpoints that were set before (or rather, their
> >> debug register information) are practically lost when the process entry
> >> point is reached.
> >>
> >> This patch creates an internal breakpoint on the process entry point, which
> >> when it is reached, resets all active hardware breakpoints, and continues
> >> execution.
> >
> > Eh, I always assumed that the initial breakpoint the Windows debug API emits
> > during process initialization _was_ the entry point.  Where does the PC
> > point at when the initial breakpoint is reached?
> >
> > You can use "starti" to check that.  "starti" spawns the process with
> > target_create_inferior, and then just does not run any other instruction,
> > It presents the stop where target_create_inferior left the process, which
> > is supposedly the process's entry point.

Somewhere in ntdll.dll (the function names are probably wrong):

(gdb) starti
Starting program: C:\src\tests\ret-types.exe

Program stopped.
0x0000000076d5cb71 in ntdll!CsrSetPriorityClass () from C:\Windows\SYSTEM32\ntdll.dll
(gdb) bt
#0  0x0000000076d5cb71 in ntdll!CsrSetPriorityClass () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x0000000076d12e85 in ntdll!RtlIsDosDeviceName_U () from C:\Windows\SYSTEM32\ntdll.dll
#2  0x0000000076cf1937 in ntdll!RtlCreateTagHeap () from C:\Windows\SYSTEM32\ntdll.dll
#3  0x0000000076cdc34e in ntdll!LdrInitializeThunk () from C:\Windows\SYSTEM32\ntdll.dll
#4  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

I think there is a lot happening before reaching the process entry point,
like calling the dll entry points.


> > If Windows indeed resets the thread context after the initial
> > process breakpoint, then it sounds like we also lose any change to
> > the registers you make after "starti".
> >
> > E.g., if you do "starti" + "p $rax = 0xabc" + "stepi", or something like
> > that.
> >
> > It it sounding to me like we should be running to the entry point
> > in the initialization loop, from within do_initial_windows_stuff?

I'm not sure that's a good idea, I would expect starti to stop where it is
now, before the dll initialization.


> The answer at <https://stackoverflow.com/questions/5925542/how-can-i-set-break-point-on-my-function-and-list-its-source>,
> seems to confirm it:
>
>   "If you debugger sets some registry values right now, those changes would not
>     matter, because OS will override all register values while starting executing
>     process. "
>
> Interestingly, it also says:
>
>   "Workaround is simple -- first make a single step using t instruction, then you
>     can use hardware breakpoints as you like."
>
> Which makes it sounds like a single-step is all it takes to get to the entry point.
> That may make it easier to implement this inside do_initial_windows_stuff,
> including doing the same thing in gdbserver.

I just tried:

(gdb) start
Temporary breakpoint 1 at 0x401a73: file ret-types.c, line 131.
Starting program: C:\src\tests\ret-types.exe

Temporary breakpoint 1, main () at ret-types.c:131
131       return func (cf);
(gdb) hb main
Hardware assisted breakpoint 2 at 0x401a73: file ret-types.c, line 131.
(gdb) c
Continuing.
[Inferior 1 (process 6228) exited with code 0317]
(gdb) starti
Starting program: C:\src\tests\ret-types.exe

Program stopped.
0x0000000076d5cb71 in ntdll!CsrSetPriorityClass () from C:\Windows\SYSTEM32\ntdll.dll
(gdb) nexti
0x0000000076d5cb73 in ntdll!CsrSetPriorityClass () from C:\Windows\SYSTEM32\ntdll.dll
(gdb) c
Continuing.
[Inferior 1 (process 2480) exited with code 0317]

So after a nexti the hardware breakpoint still didn't work, because at this
point it's far before the overwriting of the context.

Or did you mean this different?

Anyways, since there is a simple workaround to make the hardware breakpoints
work (just use "start"), it doesn't matter much to me if this gets fixed.


Hannes