From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3913 invoked by alias); 28 Nov 2013 09:07:41 -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 3902 invoked by uid 89); 28 Nov 2013 09:07:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from Unknown (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Nov 2013 09:07:38 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1VlxZB-0004lY-R6 from Hui_Zhu@mentor.com ; Thu, 28 Nov 2013 01:07:21 -0800 Received: from SVR-ORW-FEM-04.mgc.mentorg.com ([147.34.97.41]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Nov 2013 01:07:21 -0800 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.2.247.3; Thu, 28 Nov 2013 01:07:20 -0800 Message-ID: <529707C7.4040504@mentor.com> Date: Thu, 28 Nov 2013 10:56:00 -0000 From: Hui Zhu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Pedro Alves 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> <52654A2C.9010202@redhat.com> In-Reply-To: <52654A2C.9010202@redhat.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-11/txt/msg00877.txt.bz2 On 10/21/13 23:37, Pedro Alves wrote: > 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. > Hi Pedro, According to your comments. I make a new patch for it. It add a check in remote_insert_breakpoint. If this breakpoint have target breakpoint but it is not handled by "Z" packet, function will return error. Please help me review it. Because mi-dprintf.exp and dprintf.exp use "set dprintf-style agent" check if target support target-side breakpoint, they are still got fail after this patch. If you think this patch's idea is OK, I will make patch for them. Thanks, Hui 2013-11-28 Hui Zhu * remote.c (remote_insert_breakpoint): Add have_target_target_side_commands. --- a/gdb/remote.c +++ b/gdb/remote.c @@ -8187,6 +8187,14 @@ static int remote_insert_breakpoint (struct gdbarch *gdbarch, struct bp_target_info *bp_tgt) { + int have_target_target_side_commands = 0; + + /* Check bp_tgt->tcommands in this place because + remote_add_target_side_commands will release bp_tgt->tcommands. */ + + if (!VEC_empty (agent_expr_p, bp_tgt->tcommands)) + have_target_target_side_commands = 1; + /* Try the "Z" s/w breakpoint packet if it is not already disabled. If it succeeds, then set the support to PACKET_ENABLE. If it fails, and the user has explicitly requested the Z support then @@ -8240,6 +8248,13 @@ remote_insert_breakpoint (struct gdbarch } } + if (have_target_target_side_commands) + { + warning (_("\ +Target doesn't support breakpoints that have target side commands.")); + return -1; + } + return memory_insert_breakpoint (gdbarch, bp_tgt); }