From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27625 invoked by alias); 24 Feb 2016 11:52:07 -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 27607 invoked by uid 89); 24 Feb 2016 11:52:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=sometime, moribund, Hardware, HTo:U*macro 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 24 Feb 2016 11:52:05 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id D3DE985542; Wed, 24 Feb 2016 11:52:03 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u1OBq0YZ024239; Wed, 24 Feb 2016 06:52:02 -0500 Message-ID: <56CD9960.4060908@redhat.com> Date: Wed, 24 Feb 2016 11:52:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Luis Machado , "Maciej W. Rozycki" , gdb-patches@sourceware.org, linux-mips@linux-mips.org Subject: Re: [PATCH] Expect SI_KERNEL si_code for a MIPS software breakpoint trap References: <1442592647-3051-1-git-send-email-lgustavo@codesourcery.com> <56B9F7E6.5010006@codesourcery.com> <56BB329F.3080606@codesourcery.com> <56C26D8A.9070401@redhat.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-02/txt/msg00718.txt.bz2 Hi Maciej, > As to the kernel side with the observations made in this discussion I > think we should set the trap code for SIGTRAP signals issued with BREAK > instructions to TRAP_BRKPT unconditionally, regardless of the code used. > This won't of course affect encodings which send a different signal such > as SIGFPE. > > We're lacking a code suitable for (conditional) trap instructions. I > think TRAP_TRAP or suchlike needs to be added. Yeah, looks like it. >> Hardware breakpoint hits are distinguished from software breakpoint hits, >> because they're reported with "hwbreak", not "swbreak": >> >> @item hwbreak >> The packet indicates the target stopped for a hardware breakpoint. >> The @var{r} part must be left empty. > > Umm, any requirements for this? We have MIPS data hardware breakpoint > support in the Linux kernel (regrettably not for instructions, but that > could be added sometime), but I can't see TRAP_HWBKPT being set for them, > they just use generic SI_KERNEL as everything else right now. Can userspace/ptrace still tell whether a hardware breakpoint triggered by consulting debug registers, similarly to how it can for watchpoints, with PTRACE_GET_WATCH_REGS, and looking at watchhi ? (assuming this comment is correct): /* Target to_stopped_by_watchpoint implementation. Return 1 if stopped by watchpoint. The watchhi R and W bits indicate the watch register triggered. */ static int mips_linux_stopped_by_watchpoint (struct target_ops *ops) { This is not reachable today, due to lack of TRAP_* in si_code, but I think that can be fixed. The only use for hwbreak currently is to know whether to ignore hardware breakpoint traps gdb can't explain (gdb assumes they're a delayed event for a hw breakpoint that has since been removed): /* Maybe this was a trap for a hardware breakpoint/watchpoint that has since been removed. */ if (random_signal && target_stopped_by_hw_breakpoint ()) { /* A delayed hardware breakpoint event. Ignore the trap. */ if (debug_infrun) fprintf_unfiltered (gdb_stdlog, "infrun: delayed hardware breakpoint/watchpoint " "trap, ignoring\n"); random_signal = 0; } So if the server claims it supports this stop reason, but then doesn't send it for hw breakpoint trap, users will see their programs occasionally stop for random spurious SIGTRAPs (if they use hardware breapoints). If the server does _not_ claim support for the swbreak/hwbreak stop reason, then the old moribund breakpoints heuristic kicks in: /* Check if a moribund breakpoint explains the stop. */ if (!target_supports_stopped_by_sw_breakpoint () || !target_supports_stopped_by_hw_breakpoint ()) { for (ix = 0; VEC_iterate (bp_location_p, moribund_locations, ix, loc); ++ix) { if (breakpoint_location_address_match (loc, aspace, bp_addr) && need_moribund_for_location_type (loc)) { bs = bpstat_alloc (loc, &bs_link); /* For hits of moribund locations, we should just proceed. */ bs->stop = 0; bs->print = 0; bs->print_it = print_it_noop; } } } Thanks, Pedro Alves