From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100888 invoked by alias); 24 Feb 2016 18:29:51 -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 100873 invoked by uid 89); 24 Feb 2016 18:29:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=H*MI:sk:1456332, H*f:sk:1456332, H*i:sk:1456332, cell X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 Feb 2016 18:29:49 +0000 Received: from hhmail02.hh.imgtec.org (unknown [10.100.10.20]) by Websense Email Security Gateway with ESMTPS id 677C1C6078825; Wed, 24 Feb 2016 18:29:44 +0000 (GMT) Received: from [10.100.200.149] (10.100.200.149) by hhmail02.hh.imgtec.org (10.100.10.21) with Microsoft SMTP Server id 14.3.266.1; Wed, 24 Feb 2016 18:29:46 +0000 Date: Wed, 24 Feb 2016 18:29:00 -0000 From: "Maciej W. Rozycki" To: Pedro Alves CC: , "Maciej W. Rozycki" Subject: Re: [PATCH] Handle MIPS Linux SIGTRAP siginfo.si_code values In-Reply-To: <1456332239-24007-1-git-send-email-palves@redhat.com> Message-ID: References: <1456332239-24007-1-git-send-email-palves@redhat.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2016-02/txt/msg00744.txt.bz2 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? > + > + 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? 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). Maciej