From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46360 invoked by alias); 24 Feb 2016 19:02:28 -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 46313 invoked by uid 89); 24 Feb 2016 19:02:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=cell, Cell 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; Wed, 24 Feb 2016 19:02:25 +0000 Received: from svr-orw-fem-04.mgc.mentorg.com ([147.34.97.41]) by relay1.mentorg.com with esmtp id 1aYehZ-00069t-Ex from Luis_Gustavo@mentor.com ; Wed, 24 Feb 2016 11:02:21 -0800 Received: from [172.30.1.130] (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.3.224.2; Wed, 24 Feb 2016 11:02:21 -0800 Subject: Re: [PATCH] Handle MIPS Linux SIGTRAP siginfo.si_code values References: <1456332239-24007-1-git-send-email-palves@redhat.com> <56CDFB9B.3090708@redhat.com> To: Pedro Alves , "Maciej W. Rozycki" CC: , "Maciej W. Rozycki" From: Luis Machado Reply-To: Luis Machado Message-ID: <56CDFE38.1000604@codesourcery.com> Date: Wed, 24 Feb 2016 19:02:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56CDFB9B.3090708@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00751.txt.bz2 On 02/24/2016 03:51 PM, Pedro Alves wrote: > 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. I think we should converge to a standard solution across all architectures in the future rather than potentially perpetuate old non-standard ways. So the movement towards returning well defined si_code values in the MIPS Linux Kernel is a plus, even though we might not benefit from it right now. I'm in favor of having the change to the kernel made. The later we change this, the longer we need to support the old ways and their one-off mechanisms for each architecture, no?