From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5889 invoked by alias); 7 May 2015 10:48:06 -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 5832 invoked by uid 89); 7 May 2015 10:48:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f48.google.com Received: from mail-pa0-f48.google.com (HELO mail-pa0-f48.google.com) (209.85.220.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 07 May 2015 10:48:01 +0000 Received: by pacwv17 with SMTP id wv17so37049248pac.0 for ; Thu, 07 May 2015 03:48:00 -0700 (PDT) X-Received: by 10.70.125.129 with SMTP id mq1mr5899220pdb.19.1430995680012; Thu, 07 May 2015 03:48:00 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by mx.google.com with ESMTPSA id ra3sm1778901pbb.23.2015.05.07.03.47.57 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 07 May 2015 03:47:58 -0700 (PDT) From: Yao Qi To: Pedro Alves 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> Date: Thu, 07 May 2015 10:48:00 -0000 In-Reply-To: <554A368F.4060309@redhat.com> (Pedro Alves's message of "Wed, 06 May 2015 16:43:11 +0100") Message-ID: <86oalwvf38.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00139.txt.bz2 Pedro Alves writes: > Of a random PC address no, but in gdbserver's case, I think that it > would work, because we need it to step over a breakpoint that is > at the current PC. So we could: > > #1 - Get the mode of the current PC from the thread's $cpsr register. > > #2 - Get the mode of the next PC by looking at the instruction that is > about to be executed (at current PC). If bx and blx, which change > modes, check the thumb bit of the destination address. > For all other instructions, same mode as the current PC. > We can know the mode of the next PC in this way, but we don't know the address of the next PC. In fact, we need to know the address of the next PC first, and then determine the mode of the next PC. Probably, we need something as below, 1. Teach GDBserver to compute the address of the next PC, 2. Determine the mode of the next PC as you suggested, 3. Add breakpoint_from_pc hook in target_ops, so that the right breakpoint instruction can be selected. >>=20 >> After thinking about how to teach GDBserver inserting right breakpoint >> (arm or thumb) for a while, I reconsider it from a different direction >> that it may be unreasonable to run target-side conditional breakpoint for >> targets without hardware single step. Pedro also pointed this out here >> https://sourceware.org/ml/gdb-patches/2015-04/msg00337.html > > In the end I was somewhat convinced that things ended up working. > But I certainly don't object to this patch. > >> + /* Although win32-i386 has hardware single step, still disable this >> + feature for win32, because it is quite GNU/Linux specific. */ >> + NULL, /* supports_conditional_breakpoints */ > > TBC, it's not that the feature is GNU/Linux specific (like something > related to system calls or some detail in glibc), but that the support > for conditional breakpoints is baked into linux-low.c instead of > in generic code. How about writing comments like this? /* Although win32-i386 has hardware single step, still disable this feature for win32, because it is implemented in linux-low.c instead of in generic code. */ --=20 Yao (=E9=BD=90=E5=B0=A7)