From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68342 invoked by alias); 24 Feb 2016 18:51:11 -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 68305 invoked by uid 89); 24 Feb 2016 18:51:11 -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=cell, Cell 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 18:51:10 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 920676314D; Wed, 24 Feb 2016 18:51:08 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u1OIp7a5010592; Wed, 24 Feb 2016 13:51:07 -0500 Message-ID: <56CDFB9B.3090708@redhat.com> Date: Wed, 24 Feb 2016 18:51: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: gdb-patches@sourceware.org, "Maciej W. Rozycki" Subject: Re: [PATCH] Handle MIPS Linux SIGTRAP siginfo.si_code values References: <1456332239-24007-1-git-send-email-palves@redhat.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-02/txt/msg00747.txt.bz2 On 02/24/2016 06:29 PM, Maciej W. Rozycki wrote: > On Wed, 24 Feb 2016, Pedro Alves wrote: > >> @@ -140,14 +140,32 @@ struct buffer; >> in SPU code on a Cell/B.E. However, SI_KERNEL is never seen >> on a SIGTRAP for any other reason. >> >> - The generic Linux target code should use GDB_ARCH_IS_TRAP_BRKPT >> - instead of TRAP_BRKPT to abstract out these peculiarities. */ >> + The MIPS kernel uses SI_KERNEL for all kernel generated traps. >> + Since: >> + >> + - MIPS doesn't do hardware single-step >> + - We don't need to care about exec SIGTRAPs, since we assume >> + PTRACE_EVENT_EXEC. >> + - The MIPS kernel doesn't support hardware breakpoints. >> + >> + on MIPS, all we need to care about is distinguishing between >> + software breakpoints and hardware watchpoints, which can be done by >> + peeking the debug registers. > > I'm assuming spurious traps such as from trap instructions will still be > delivered as such, right? Yes, they should. > >> + >> + The generic Linux target code should use GDB_ARCH_IS_TRAP_* instead >> + of TRAP_* to abstract out these peculiarities. */ >> #if defined __i386__ || defined __x86_64__ >> # define GDB_ARCH_IS_TRAP_BRKPT(X) ((X) == SI_KERNEL) >> +# define GDB_ARCH_IS_TRAP_HWBKPT(X) ((X) == TRAP_HWBKPT) >> #elif defined __powerpc__ >> # define GDB_ARCH_IS_TRAP_BRKPT(X) ((X) == SI_KERNEL || (X) == TRAP_BRKPT) >> +# define GDB_ARCH_IS_TRAP_HWBKPT(X) ((X) == TRAP_HWBKPT) >> +#elif defined __mips__ >> +# define GDB_ARCH_IS_TRAP_BRKPT(X) ((X) == SI_KERNEL) >> +# define GDB_ARCH_IS_TRAP_HWBKPT(X) ((X) == SI_KERNEL) > > Shall I add the TRAP_BRKPT and TRAP_HWBKPT codes to the MIPS Linux kernel > then or not? The higher order issue was having a way to distinguish the possible traps, for correctness. Since we found a way, it's no longer a pressing issue and we could leave it be. > If anything, this looks like a performance win to me, at no > significant cost (any possible kernel overhead will be in the range of a > couple processor instructions, which is nothing compared to an extra > ptrace(2) call and all the associated processing). Yeah. We usually need several other ptrace calls so it may not be noticeable. But if you do teach the kernel about TRAP_BRKPT, and want to avoid the watchpoints check, I think gdb/gdbserver could be made to auto detect at run time what does the kernel report. E.g,. have gdb fork itself, set a sw bp at the current PC in the child and continue it. That triggers the bp immediately. Then the parent can check what is in the child's si_code. We do similar things already in linux_check_ptrace_features (gdb/nat/linux-ptrace.c). Thanks, Pedro Alves