From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22987 invoked by alias); 3 Jun 2014 09:43:09 -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 22972 invoked by uid 89); 3 Jun 2014 09:43:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Jun 2014 09:43:05 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1WrlFE-0006wI-TO from Yao_Qi@mentor.com ; Tue, 03 Jun 2014 02:43:00 -0700 Received: from SVR-ORW-FEM-06.mgc.mentorg.com ([147.34.97.120]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jun 2014 02:43:00 -0700 Received: from qiyao.dyndns.org (147.34.91.1) by SVR-ORW-FEM-06.mgc.mentorg.com (147.34.97.120) with Microsoft SMTP Server id 14.2.247.3; Tue, 3 Jun 2014 02:43:00 -0700 Message-ID: <538D982A.4070404@codesourcery.com> Date: Tue, 03 Jun 2014 09:43:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Pedro Alves , Subject: Re: [pushed] Don't suppress errors inserting/removing hardware breakpoints in shared libraries. References: <1398262082-12503-1-git-send-email-palves@redhat.com> In-Reply-To: <1398262082-12503-1-git-send-email-palves@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00074.txt.bz2 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 1) remove hbreak-unmapped.exp and hbreak-unmapped.c 2) or skip hbreak-unmapped.exp on bare metal and uclinux targets, 3) or relax the pattern What do you think? -- Yao (齐尧)