From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11720 invoked by alias); 5 Jun 2014 16:02:18 -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 11708 invoked by uid 89); 5 Jun 2014 16:02:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Jun 2014 16:01:54 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s55G1pYs017947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Jun 2014 12:01:51 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s55G1nIh014816; Thu, 5 Jun 2014 12:01:50 -0400 Message-ID: <5390946C.6010408@redhat.com> Date: Thu, 05 Jun 2014 16:02:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Yao Qi , gdb-patches@sourceware.org Subject: Re: [pushed] Don't suppress errors inserting/removing hardware breakpoints in shared libraries. References: <1398262082-12503-1-git-send-email-palves@redhat.com> <538D982A.4070404@codesourcery.com> In-Reply-To: <538D982A.4070404@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-06/txt/msg00271.txt.bz2 On 06/03/2014 10:40 AM, Yao Qi wrote: > On 04/23/2014 10:08 PM, Pedro Alves wrote: >> +# Hardware breakpoints are implemented using a mechanism that is not >> +# dependent on being able to modify the target's memory, we should be >> +# able to set them even in unmapped memory areas. >> +gdb_test "hbreak *0" "Hardware assisted breakpoint \[0-9\]+ at 0x0" >> + >> +gdb_test "info break" "hw breakpoint.*y.*0x0\+\[ \t\]\+" \ >> + "info break shows hw breakpoint" > > These two tests fail on arm-none-eabi target, > > hbreak *0^M > Hardware assisted breakpoint 3 at 0x0: file > /scratch/yqi/arm-none-eabi-lite/obj/cs3-2014.11-999999-arm-none-eabi-i686-pc-linux-gnu/generated/arm-vector.S, > line 25.^M > (gdb) FAIL: gdb.base/hbreak-unmapped.exp: hbreak *0 > info break^M > Num Type Disp Enb Address What^M > 3 hw breakpoint keep y 0x00000000 > /scratch/yqi/arm-none-eabi-lite/obj/cs3-2014.11-999999-arm-none-eabi-i686-pc-linux-gnu/generated/arm-vector.S:25^M > (gdb) FAIL: gdb.base/hbreak-unmapped.exp: info break shows hw breakpoint > delete $bpnum > > because the vector table base address is 0x0. > > We can either relax the regex pattern or skip this test on bare metal > targets. However, after I read the commit log, I find > hbreak-unmapped.exp isn't necessary because we've already had > hbreak-in-shr-unsupported.exp. I don't see anything hbreak-unmapped.exp > can cover while hbreak-in-shr-unsupported.exp doesn't. I suggest we They're opposites. The real tests are not the "hbreak main" parts, which is the tests probing target features, but what follows. The former tests that inserting a hbreak in an unmapped region doesn't error. While the latter tests that inserting a hbreak in a mapped region when the target doesn't support hbreak at all results in an error. > 2) or skip hbreak-unmapped.exp on bare metal and uclinux targets, Yes, but no need to match by target, we can do like e.g., gdb.base/signull.exp does, and check whether "x /b 0" manages to read memory. If so, then skip the test. Any sane target with an MMU will leave page 0 unmapped, so no need to look for some other address. -- Pedro Alves