From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73082 invoked by alias); 11 May 2015 17:40:39 -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 73073 invoked by uid 89); 11 May 2015 17:40:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-HELO: cvs.linux-mips.org Received: from eddie.linux-mips.org (HELO cvs.linux-mips.org) (148.251.95.138) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 11 May 2015 17:40:37 +0000 Received: (from localhost user: 'macro', uid#1010) by eddie.linux-mips.org with ESMTP id S27027433AbbEKRkd2OaaV (ORCPT ); Mon, 11 May 2015 19:40:33 +0200 Date: Mon, 11 May 2015 17:40:00 -0000 From: "Maciej W. Rozycki" To: Pedro Alves cc: Yao Qi , gdb-patches@sourceware.org Subject: Re: [PATCH] [gdbserver] Disable conditional breakpoints on no-hardware-single-step targets In-Reply-To: <5550B7D7.30902@redhat.com> Message-ID: References: <1430411029-12097-1-git-send-email-qiyaoltc@gmail.com> <554A368F.4060309@redhat.com> <55509310.6040909@redhat.com> <5550B7D7.30902@redhat.com> User-Agent: Alpine 2.11 (LFD 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00258.txt.bz2 On Mon, 11 May 2015, Pedro Alves wrote: > > And that's where the issue is. Assuming that you're in the standard ISA > > mode, you can determine that the next instruction will switch the mode to > > one of the compressed ISAs, either by checking the opcode (immediate jump, > > JALX) or by reading the PC to be jumped to (register jumps, JALR and JR). > > What you can't determine is which of the two compressed ISAs, either > > MIPS16 or microMIPS one, the instruction will switch to. > > > > Given that the MIPS16 and the microMIPS mode cannot be implemented by a > > processor both at a time you can will know which of the two is being used > > once you have seen a breakpoint request for one of them. However it may > > be that none has been used so far and then you have no way to know, in the > > current state of affairs. > > That sounds solvable though: as that's a static property of the > target system/process, maybe gdbserver can fetch that info from elsewhere, > like somewhere under /proc, or from the auvx, or some bit set in the elf > binary (found at /proc/pid/exe). Failing that, we can have gdb tell > gdbserver early with some new packet. Good point, thanks for the hint! Gdbserver itself can indeed peek at the executable, and binaries that contain microMIPS code will have that noted in the ELF header, in `e_flags'. Conversely, the lack of such annotation implies the MIPS16 mode -- if ever requested, that is, as the lack of microMIPS annotation does not mean any MIPS16 code is actually present, it may in fact be a plain MIPS binary. So there's still the corner case of a MIPS16 binary accidentally run on microMIPS hardware, as that cannot be detected until a switch to the compressed mode has been made. In which case the debuggee will likely crash anyway, so it might not be an interesting case to handle; otherwise perhaps the presence of support for the MIPS16 or microMIPS instruction set is something worth exporting via AT_HWCAP. I don't know offhand how the two microMIPS software breakpoint instruction encodings used by GDB decode in the MIPS16 instruction set. Another issue is AFAIK the Linux kernel does not check the microMIPS flag in `e_flags' either and will happily attempt to run such a binary on MIPS16 or plain MIPS hardware. But if anything, that's a kernel bug. Maciej