From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9550 invoked by alias); 1 Jul 2015 16:43:02 -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 9515 invoked by uid 89); 1 Jul 2015 16:43:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no 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; Wed, 01 Jul 2015 16:43:00 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id D0F33B1F8B; Wed, 1 Jul 2015 16:42:59 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t61GgwPF025281; Wed, 1 Jul 2015 12:42:59 -0400 Message-ID: <55941892.3000902@redhat.com> Date: Wed, 01 Jul 2015 16:43: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: Yao Qi , gdb-patches@sourceware.org Subject: Re: [PATCH 11/11] New target_ops hook to_can_do_single_step References: <1435759111-22856-1-git-send-email-yao.qi@linaro.org> <1435759111-22856-12-git-send-email-yao.qi@linaro.org> In-Reply-To: <1435759111-22856-12-git-send-email-yao.qi@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-07/txt/msg00057.txt.bz2 On 07/01/2015 02:58 PM, Yao Qi wrote: > Nowadays, GDB only knows whether architecture supports hardware single > step or software single step (through gdbarch hook software_single_step), > and for a given instruction or instruction sequence, GDB knows how to > do single step (hardware or software). However, GDB doesn't know whether > the target supports hardware single step. It is possible that the > architecture doesn't support hardware single step, such as arm, but > the target supports, such as simulator. This was discussed in this > thread https://www.sourceware.org/ml/gdb/2009-12/msg00033.html before. > > I encounter this problem for aarch64 multi-arch support. When aarch64 > debugs arm program, gdbarch is arm, so software single step is still > used. However, the underneath linux kernel does support hardware > single step, so IWBN to use it. > > This patch is to add a new target_ops hook to_can_do_single_step, and > only use it in arm_linux_software_single_step to decide whether or not > to use hardware single step. On the remote target, if the target > supports s and S actions in the vCont? reply, then target can do single > step. On the native aarch64 linux target, 1 is returned. On other > targets, -1 is returned. Yeah, I've wanted to do this before too. But my issue with it is that this breaks gdb/gdbserver compatibility. Old GDB has: /* If s, S, c, and C are not all supported, we can't use vCont. Clearing BUF will make packet_ok disable the packet. */ if (!support_s || !support_S || !support_c || !support_C) buf[0] = 0; Which means that new x86-86 gdbserver with old gdb will just stop using vCont after this change. And old arm gdbserver will still claim support for vCont;s packets, which means that new gdb with old gdbserver will be broken. I think this needs to be addressed somehow. Thanks, Pedro Alves