From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49384 invoked by alias); 11 May 2015 14:08:27 -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 49373 invoked by uid 89); 11 May 2015 14:08:26 -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,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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; Mon, 11 May 2015 14:08:26 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id EF5918E674; Mon, 11 May 2015 14:08:24 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4BE8Nxw005996; Mon, 11 May 2015 10:08:24 -0400 Message-ID: <5550B7D7.30902@redhat.com> Date: Mon, 11 May 2015 14:08:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Maciej W. Rozycki" CC: Yao Qi , gdb-patches@sourceware.org Subject: Re: [PATCH] [gdbserver] Disable conditional breakpoints on no-hardware-single-step targets References: <1430411029-12097-1-git-send-email-qiyaoltc@gmail.com> <554A368F.4060309@redhat.com> <55509310.6040909@redhat.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-05/txt/msg00254.txt.bz2 On 05/11/2015 01:37 PM, Maciej W. Rozycki wrote: > On Mon, 11 May 2015, Pedro Alves wrote: >> I assume that mode switches on MIPS are similar to ARM, with special >> branch instruction with mode encoded in in destination address? If so, >> starting from knowing the mode at PC, gdbserver should be able to >> determine the mode of all the potential next instructions on its own. > > 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. Thanks, Pedro Alves