From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75978 invoked by alias); 16 Feb 2016 00:57:41 -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 75807 invoked by uid 89); 16 Feb 2016 00:57:40 -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=plants, planted, anchor, distinguished 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; Tue, 16 Feb 2016 00:57:39 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 0A2E3804E7; Tue, 16 Feb 2016 00:57:38 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u1G0vZ57016391; Mon, 15 Feb 2016 19:57:36 -0500 Message-ID: <56C273FF.7070206@redhat.com> Date: Tue, 16 Feb 2016 00:57: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: Luis Machado , "Maciej W. Rozycki" CC: "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> In-Reply-To: <56BB329F.3080606@codesourcery.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-02/txt/msg00477.txt.bz2 On 02/10/2016 12:52 PM, Luis Machado wrote: > The problem of forcing gdbserver to recognize all traps with > si_code==SI_KERNEL is that even hardcoded traps will be reported back to > GDB as a swbreak event, which is not ideal. That's how swbreak is defined: @item swbreak @anchor{swbreak stop reason} The packet indicates a memory breakpoint instruction was executed, irrespective of whether it was @value{GDBN} that planted the breakpoint or the breakpoint is hardcoded in the program. > > But currently there is no easy way to tell a software breakpoint hit and > a hardcoded trap (and maybe even a hardware breakpoint hit?) apart. Software breakpoint hits or hardcoded traps are handled the same. Even if GDB plants the breakpoint instruction itself with direct memory pokes (instead of z0 packets), the target should report "swbreak" stops, so that gdb can do the right thing. GDB knows whether to discard the hit as a delayed breakpoint hit event by checking whether the thread's PC points at an hardcoded trap. If it does, the event is not discarded, but instead reported to the user as a SIGTRAP. 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. Thanks, Pedro Alves