From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3230 invoked by alias); 14 Feb 2019 22:42:39 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 3211 invoked by uid 89); 14 Feb 2019 22:42:39 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=H*UA:6.1, H*u:6.1 X-HELO: userp2130.oracle.com Received: from userp2130.oracle.com (HELO userp2130.oracle.com) (156.151.31.86) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 14 Feb 2019 22:42:37 +0000 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x1EMdvqb001863; Thu, 14 Feb 2019 22:42:30 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=qBHLI2VAQZFhQuhmB/ZU/gDAhlU3+YTHk3CyJQVT0VU=; b=oliI6T+I5Jvg9JYyUgYDKyVF6vnTe0lX8joTW6cQsSevEkzDGMPE6fZhockQRoOesNrO ukCgRRL0xkPDIsUOzWPc14uuEr4qVjSOoIWSv+LNmzkzk8Kput4S4RXeLhL1yE2Z/k0S XaERyFPCUL4RuZ0G89hVPQj9x4rCbZIjbV8DfgP8IvScNL69BBSSnpanp7x+Ci1jCFQc 6RzKhFpJmYZAy8f/VPjxKnPIiC3GfZ5dXmD/+EEf8z37HLl3UhbmKQwGKBZGETyIy6Iy 9Q6lbGJHU24pixJPWnAebu9+7y7hfJEh7DkotU0AJmUYWeZzn4Cgyf657egifNKd6mg6 Qg== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2130.oracle.com with ESMTP id 2qhrekts29-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Feb 2019 22:42:30 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x1EMgTT0028930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Feb 2019 22:42:29 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x1EMgSC3008400; Thu, 14 Feb 2019 22:42:29 GMT Received: from [10.159.151.52] (/10.159.151.52) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 Feb 2019 14:42:28 -0800 Subject: Re: [PING][PATCH v2 PR gdb/21870] aarch64: Leftover uncleared debug registers To: Pedro Alves , Alan Hayward Cc: "gdb-patches@sourceware.org" , nd References: <1530148222-12558-1-git-send-email-weimin.pan@oracle.com> <145f2e8d-4321-00a6-650a-bf8f0a483b6f@oracle.com> <7861E9FA-0293-4C16-857A-6935579C7042@arm.com> <3eea53e4-dfc6-ef59-f88f-d35797c26ba6@oracle.com> <31396591-A287-40C5-A4D0-6EAEC8077D6B@arm.com> <563997a0-cd3c-cf6e-8418-bbd452436b2b@oracle.com> <037877d7-a3d3-7ae1-cafa-0bd29927abb2@redhat.com> <3fc1501e-cbf7-7d92-e5a2-8a3ccd4e332e@oracle.com> <2465cc32-c77d-d100-dde7-419df22e9ae7@redhat.com> From: Wei-min Pan Message-ID: Date: Thu, 14 Feb 2019 22:42:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <2465cc32-c77d-d100-dde7-419df22e9ae7@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2019-02/txt/msg00242.txt.bz2 On 2/14/2019 5:01 AM, Pedro Alves wrote: > On 02/13/2019 09:56 PM, Wei-min Pan wrote: >> On 2/13/2019 3:40 AM, Pedro Alves wrote: >>> On 02/12/2019 01:10 AM, Weimin Pan wrote: >>>> +clean_restart $testfile >>>> + >>>> +set test "run to exit" >>>> +gdb_test_multiple "run" "$test" { >>>> +    -re "exited with code 01.*$gdb_prompt $" { >>>> +        pass "$test" >>>> +    } >>>> +    -re "exited normally.*$gdb_prompt $" { >>>> +        pass "$test" >>>> +    } >>>> +} >>> A naked "run" command doesn't work when testing against >>> gdbserver with --target_board=native-gdbserver. >>> >>> Is "run" important here?  Could this use runto_main + "continue" instead? >> As long as the test run doesn't assert, we could instead use >> "runto_main + "continue". Thanks for pointing this out. > OOC, why does asserting make a difference? > >>> Also, the comment at the top of the file says: >>> >>>   # This test checks that GDB does not alter watchpoints set by an inferior. >>>   # It sets a watchpoint on memory then writes to the watched memory. >>>   # It will exit with 1 if the watchpoint is not reached. >>> >>> But I couldn't spot where that "exit with 1" happens in the .c file. >> You are right, it should be "exit with 2". >> >>> Also, when that happens, we're issuing a pass, as seen above. >>> Is that intended? >> "Exit with 1" could happen if the PTRACE_SETREGSET call should >> fail which is ok as long as it doesn't cause assertion. > I see. Could you add some comments, please? Done. > Could you send a patch? Just pushed the updated patch. > BTW: > > - why is the SET_WATCHPOINT macro necessary? It's not necessary. Removed. > > - what does the ??? below mean? > > dreg_state.dbg_regs[0].ctrl |= 2 << 1; // GDB: ???: enabled at el0 Removed the "GDB: ???:" part. > > - The code has: > > atexit (cleanup); > > (...) > > but then also calls cleanup() return returning (twice, end of main), > which seems unnecessary? You're right, the second call is redundant and is removed. > > - While at it, the gdb_compile + clean_restart in the .exp file > could be replaced with a single prepare_for_testing call. Nice. Replaced. Thanks. > >> Thanks for your comments. >> > Thanks, > Pedro Alves