From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by sourceware.org (Postfix) with ESMTP id ABF043887019 for ; Wed, 27 May 2020 12:07:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org ABF043887019 Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-480-hOao1TWOM6y-zyuSHa0hqw-1; Wed, 27 May 2020 08:07:11 -0400 X-MC-Unique: hOao1TWOM6y-zyuSHa0hqw-1 Received: by mail-wr1-f69.google.com with SMTP id j8so4392187wrb.9 for ; Wed, 27 May 2020 05:07:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5Lk0HAoefY81DaipXZPLxcG9w9zA1bIxbxkf7qjeZNU=; b=LjJd1VuiQmRcvbVPN2r8wkE1fzJso52lHfHT4rwvR437/C1A2dXcP/GHrdlbLCOqzg dky0YE2d1THzEYIfOIDcqXrb7Of2pTDWxRABd2aOGd0QNmTXYpKA8yYGFbOZmVfc6wcT bQK9UTgPPBT+uGqe0OwwVPPlQH7WjzbeVQs8N30t717b/lw9MV6fx3F4szIxGT+VdamQ h/7j2BL+2KK6nSf4GNf9FN14+kkNt/sZT1pC6AshDvKlZmrvQpIBUDhQcY0t1KjwHEZN kKjTxqIqkNj/Sw9f4Y+lZzbntHS+ILze3RFRGPuxlXHj4W60jKK4ZtSR//5g8iwXgbSc G8uA== X-Gm-Message-State: AOAM531usG9JS5Whwhh81rYKxl3YCVXXn7+iNwEq/934VMN144pKlhal cDvD2r6gWfvbKESQiT7/x1S5oEFxmzTWS9kBNukvs3bB+U9lufW1XgESz+qvs0DyybEYdkJGLUZ YHhPD538xKIA7zyeWZw7BMg== X-Received: by 2002:a1c:2e46:: with SMTP id u67mr3868149wmu.156.1590581230269; Wed, 27 May 2020 05:07:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyVk3RQBxnFME+SRMkUz7iGTkgHEALU2M90EBHHoG3xfFJfaLnSIzcfof8CB3oCrqO2kwACnA== X-Received: by 2002:a1c:2e46:: with SMTP id u67mr3868124wmu.156.1590581229950; Wed, 27 May 2020 05:07:09 -0700 (PDT) Received: from ?IPv6:2001:8a0:f909:7b00:56ee:75ff:fe8d:232b? ([2001:8a0:f909:7b00:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id o15sm2721501wrv.48.2020.05.27.05.07.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2020 05:07:09 -0700 (PDT) Subject: Re: [PATCH 7/7] Reset Windows hardware breakpoints on executable's entry point To: Hannes Domani , gdb-patches@sourceware.org References: <20200525185659.59346-1-ssbssa@yahoo.de> <20200525185659.59346-8-ssbssa@yahoo.de> From: Pedro Alves Message-ID: Date: Wed, 27 May 2020 13:07:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20200525185659.59346-8-ssbssa@yahoo.de> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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 12:07:15 -0000 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. 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? Thanks, Pedro Alves