From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic308-18.consmr.mail.ir2.yahoo.com (sonic308-18.consmr.mail.ir2.yahoo.com [77.238.178.146]) by sourceware.org (Postfix) with ESMTPS id F306E3959C66 for ; Wed, 27 May 2020 15:39:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F306E3959C66 X-YMail-OSG: NOlfYA0VM1mu0a69LJwlWUkBMzRfSz.ucs.WBbxEOZPg5D76L6j.x2iHK_OpM5E qdADCTA9_DsqOxCSAscG0b7aF7QdVR_Y9WSCd7QzjJPjPUnXYVMCjKXB.2mWI2wrdcZrplSpjwYg BXZpr.fJKW6mIPf19upmmvaccX4kajvt_ZVGI1FntTXr.N2df9zzejiVgGJZ6VDFZGfqWTwZ94D0 N98zw.IEK2yz5Dpa0ME6hc4IiwrePq6sQ5fqrvtdt2nw3d4yA.NMRzgH0CmRLgGtHuVsx1EalI9g PZIWIVZBh9SW_LQTatz2FzVH_aIVLx8Vbbk_LfbbDu5LmdsjVubOUw6wLtazDqVdz73DADa.p9_8 .uZD5jm0ApAIj3gccYaspMVCCsKDrHicvg6F1V4OmmwiUEuMiGM0pSz_FXEMdjU.XUvccIrinSvt yebrVFsDWp8kNIck7IDUOAC_O3yHcFCk7mwF8dQahbDSigl27s9ZXibaZbDwdb1WALjd6291kQd5 cvO0Vir4iMJ8duDUZHQ6qLFeFPNsMMo85t7uY.r7UhZ0DXiB96l_dTN5zv2tD.DVPhKzVtq1Zoxw NOzKt2MLurFXGzyz3D2dh4LvGMLqOeEVPHr1BVse80NtT8N94gvjxflfmwrNprG2qTzTXJJnxBSE N2sI7IDnbsKeJu3YLsN522LGZIM5R2tNi8fjyal0tOhucKN4uKFMrTel2GFYLif2CY6dCXd_TSR_ RV_p.glM9iFVgBs2d_xnbfn4zIGENQU4UXUNRdrfBG0N5XZcP7JIiVHCmdKf2uSiLoI7ReoU3eLf Qx7Ob3no.BHZA5vers5aqKdE2ZrXrbURDdoK_Wey1wmipPQ7Svb1WTNbW70gP64PjHQy2e0Bc36Q qMOxp1Wt6A59W18VGI5zxKQ1JMqLQtFCdi9bsJ9ZEe3LR4oWbTS15zu0h5TDgKmhU2Rqkn4yEtlO 9gkPYY_JPN7THXFGJQ.vF_ngq8fwUQW8IhQyDqJxn_zMnx8qNBU_3xIDIlETpuKs4tHkrAj1aVaU JIWUrjkeEk1mwZZZC77GIHFR313Jzd0YcGRvdeWMNiSP2ueo_qIxq3cvOE965ARe2h1iNxulhLFR t8McSZ4GmzEv4TrWG1XccL2_oAy_VnIuWAONjdUQVpsRwpLEdle4BamTpEncan5vbmHyEMHnrHT2 YrLTcyHEIAQKID4hEHRMDGxQDzBlT4x6yz4_Z.FFDvzes7lXCARcdf0rPieSKnuWnZxSFpD3oWNH rfu2sEhZJh1HWzEa5lKDdjJKN7oWoMOJclA41NolnJfGrj0NqybJlG4wq5NY6sBOcESFUwNPe2HD 6TDlqIz8Mg5FpKTsL Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ir2.yahoo.com with HTTP; Wed, 27 May 2020 15:39:51 +0000 Date: Wed, 27 May 2020 15:39:48 +0000 (UTC) From: Hannes Domani To: Gdb-patches Message-ID: <262511602.870722.1590593988931@mail.yahoo.com> In-Reply-To: <8e076c81-6e92-930f-c16d-1db73bde8a83@redhat.com> References: <20200525185659.59346-1-ssbssa@yahoo.de> <20200525185659.59346-8-ssbssa@yahoo.de> <8e076c81-6e92-930f-c16d-1db73bde8a83@redhat.com> Subject: Re: [PATCH 7/7] Reset Windows hardware breakpoints on executable's entry point MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.15959 YMailNorrin Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0 X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 15:39:53 -0000 Am Mittwoch, 27. Mai 2020, 16:48:16 MESZ hat Pedro Alves 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, op= timized 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.bas= e\hbreak2\ > >> hbreak2.exe > >> > >> Temporary breakpoint 1, main (argc=3D1, argv=3D0x7e2120, envp=3D0x7e29= 00) > >>=C2=A0=C2=A0=C2=A0 at C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.b= ase/break.c:43 > >> 43=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (argc =3D= =3D 12345) {=C2=A0 /* 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.bas= e\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.bas= e\hbreak2\ > >> hbreak2.exe > >> > >> Temporary breakpoint 3, main (argc=3D1, argv=3D0x322120, envp=3D0x3229= 00) > >>=C2=A0=C2=A0=C2=A0 at C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.b= ase/break.c:43 > >> 43=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (argc =3D= =3D 12345) {=C2=A0 /* an unlikely value < 2^16, in case uninited > >> */ /* set breakpoint 6 here */ > >> (gdb) c > >> Continuing. > >> > >> Breakpoint 2, factorial (value=3D6) > >>=C2=A0=C2=A0=C2=A0 at C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.b= ase/break.c:63 > >> 63=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (value > 1) {=C2=A0 /*= 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 entr= y > >> 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 contin= ues > >> execution. > > > > Eh, I always assumed that the initial breakpoint the Windows debug API = emits > > during process initialization _was_ the entry point.=C2=A0 Where does t= he PC > > point at when the initial breakpoint is reached? > > > > You can use "starti" to check that.=C2=A0 "starti" spawns the process w= ith > > target_create_inferior, and then just does not run any other instructio= n, > > It presents the stop where target_create_inferior left the process, whi= ch > > 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=C2=A0 0x0000000076d5cb71 in ntdll!CsrSetPriorityClass () from C:\Windows= \SYSTEM32\ntdll.dll #1=C2=A0 0x0000000076d12e85 in ntdll!RtlIsDosDeviceName_U () from C:\Window= s\SYSTEM32\ntdll.dll #2=C2=A0 0x0000000076cf1937 in ntdll!RtlCreateTagHeap () from C:\Windows\SY= STEM32\ntdll.dll #3=C2=A0 0x0000000076cdc34e in ntdll!LdrInitializeThunk () from C:\Windows\= SYSTEM32\ntdll.dll #4=C2=A0 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 =3D 0xabc" + "stepi", or something l= ike > > 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 , > seems to confirm it: > >=C2=A0=C2=A0 "If you debugger sets some registry values right now, those c= hanges would not >=C2=A0=C2=A0=C2=A0=C2=A0 matter, because OS will override all register val= ues while starting executing >=C2=A0=C2=A0=C2=A0=C2=A0 process. " > > Interestingly, it also says: > >=C2=A0=C2=A0 "Workaround is simple -- first make a single step using t ins= truction, then you >=C2=A0=C2=A0=C2=A0=C2=A0 can use hardware breakpoints as you like." > > Which makes it sounds like a single-step is all it takes to get to the en= try 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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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 breakpoint= s work (just use "start"), it doesn't matter much to me if this gets fixed. Hannes