From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67934 invoked by alias); 28 Sep 2015 21:01:30 -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 67920 invoked by uid 89); 28 Sep 2015 21:01:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: usevmg20.ericsson.net Received: from usevmg20.ericsson.net (HELO usevmg20.ericsson.net) (198.24.6.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 28 Sep 2015 21:01:28 +0000 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 3C.07.32596.93B49065; Mon, 28 Sep 2015 16:14:17 +0200 (CEST) Received: from [142.133.110.95] (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.83) with Microsoft SMTP Server id 14.3.248.2; Mon, 28 Sep 2015 17:01:26 -0400 Subject: Re: [PATCH 2/5] Make breakpoint and breakpoint_len local variables in GDBServer. To: Eli Zaretskii , Yao Qi References: <1442577749-6650-1-git-send-email-antoine.tremblay@ericsson.com> <1442577749-6650-3-git-send-email-antoine.tremblay@ericsson.com> <867fna98d3.fsf@gmail.com> <83a8s6eu55.fsf@gnu.org> CC: From: Antoine Tremblay Message-ID: <5609AAA5.5020707@ericsson.com> Date: Mon, 28 Sep 2015 21:01:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <83a8s6eu55.fsf@gnu.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00615.txt.bz2 On 09/28/2015 06:05 AM, Eli Zaretskii wrote: >> From: Yao Qi >> Cc: >> Date: Mon, 28 Sep 2015 10:54:48 +0100 >> >> After thinking about it a bit more, I think this reveals some design >> issues in GDBserver brekapoint, nowadays, GDBserver inserts its own >> breakpoints and breakpoints requested by GDB. After this patch series, >> GDBserver should be able to: >> >> 1) choose the right breakpoint instruction for its own breakpoints, >> according to the breakpoint address, status register flag, etc, >> through API set_breakpoint_at, >> 2) choose the right breakpoint instruction for breakpoints requested >> by GDB, according to the information in Z packets, through API >> set_gdb_breakpoint >> >> there should be two paths for them, and each path needs different target >> hook to choose breakpoint instructions. breakpoint_from_pc is needed for >> #1, and breakpoint_from_length is needed for #2. In your current patch >> set (in patch 4/5), two things are mixed together, which doesn't look >> good to me. The current functions calls in GDBserver to create >> breakpoint is like >> >> set_breakpoint_at >> set_gdb_breakpoint_1 >> | >> `--> set_breakpoint >> | >> `-->set_raw_breakpoint_at >> | >> `--> the_target->insert_point >> >> we are handling the breakpoint length at the lowest level, in >> insert_memory_breakpoint, and we use breakpoint_from_pc and >> breakpoint_from_length together there, which looks unclean. Ideally, we >> can move these code handling breakpoint length (breakpoint_from_pc and >> breakpoint_from_length) to upper levels, like this, >> >> set_breakpoint_at (call breakpoint_from_pc) >> set_gdb_breakpoint_1 (call breakpoint_from_length) >> | >> `--> set_breakpoint >> | >> `-->set_raw_breakpoint_at >> | >> `--> the_target->insert_point >> >> all needed information is saved in struct breakpoint or struct >> raw_breakpoint, and function set_breakpoint and it callees can use >> breakpoint or raw_breakpoint directly. It'll be cleaner in this way, >> let me know what do you think? > > Sometimes only the target layer knows how to choose the length > correctly. Are we sure this isn't one of those cases, and can never > be? > breakpoint_from_pc and breakpoint_from_length are target ops so indeed only the target knows but it's ok we can query the target properly.