From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9026 invoked by alias); 21 Oct 2013 15:37:22 -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 9013 invoked by uid 89); 21 Oct 2013 15:37:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS 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 ESMTP; Mon, 21 Oct 2013 15:37:20 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r9LFbIQ2016442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Oct 2013 11:37:19 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r9LFbHk3022880; Mon, 21 Oct 2013 11:37:18 -0400 Message-ID: <52654A2C.9010202@redhat.com> Date: Mon, 21 Oct 2013 15:37:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Hui Zhu CC: gdb-patches ml Subject: Re: [PATCH] Let gdbserver doesn't tell GDB it support target-side breakpoint conditions and commands if it doesn't support 'Z' packet References: <5265022F.8060203@mentor.com> In-Reply-To: <5265022F.8060203@mentor.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-10/txt/msg00640.txt.bz2 On 10/21/2013 11:30 AM, Hui Zhu wrote: > We found that in powerpc arch board, it cannot pass some dprintf test: > FAIL: gdb.base/dprintf.exp: dprintf info 2 (pattern 6) > FAIL: gdb.mi/mi-dprintf.exp: mi expect stop (unknown output after running) > FAIL: gdb.mi/mi-dprintf.exp: mi 1st dprintf, agent (unknown output after running) > > This because the gdbserver will always tell GDB that it support target-side breakpoint conditions and commands. So "set dprintf-style agent" will always got success. > But target-side breakpoint conditions and commands are depend on 'Z' packet because GDB just can post target-side breakpoint conditions and commands with 'Z' packet. > The test will check if "set dprintf-style agent" success or not. Because it will always succes. So GDB change the commands to agent-printf that will make test get fail. There happens to be a single "the_low_target.insert_point" entry point in gdbserver for all sorts of Z packets. But Z0, Z1, Z2, etc., they're all different packets (software breakpoints, hardware breakpoints, watchpoints, etc.). A target might well support Z1 but not Z0. Or it may support Z2/Z3/Z4, but not Z0..Z1 -- that's the case of MIPS gdbserver. So, having a "the_low_target.insert_point" hook installed does not actually mean that dprintf will work. (Consider what the patch would need to do if instead of a single "the_low_target.insert_point" entry point, we had one for each Zx packet.) In the general case, gdbserver can't possibly know what packet GDB will want to send with target conditions or target commands in. GDB could end up sending either a Z0, or a Z1. The target might support Z1, but not Z0, leaving gdb to handle memory breakpoints. The concept of target-side conditions and commands is broader than dprintf. I think that first, GDB should be taught to handle this scenario itself. That is, if we try this against gdbserver: (gdb) set dprintf-style agent (gdb) set remote Z-packet off (gdb) dprint main,"foo" Dprintf 1 at 0x410776: file foo.c, line 10. (gdb) c GDB should realize that the dprintf won't work, right at insertion time, but, it currently does not. -- Pedro Alves