From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [IPv6:2a00:1450:4864:20::643]) by sourceware.org (Postfix) with ESMTPS id 655B6386F442 for ; Thu, 11 Jun 2020 09:40:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 655B6386F442 Received: by mail-ej1-x643.google.com with SMTP id mb16so5795733ejb.4 for ; Thu, 11 Jun 2020 02:40:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-description:content-disposition:in-reply-to; bh=CGGcZt4MNDLzkWaEJBclrVEedvak4XVVeEGgdMGTn8s=; b=NmzUZXOAGaExSFTsEE1xzU411udWYGKvNAktWKB2c3sBSV9OuiB+hnDxRh2xDuERj1 c1sQtnT5iIrMBGTcwebrjMncdJdnlh3n7z+OuXLSb/DSkDhoOu5tBu3oAD5NtVivjA8n bd6d9K4d7eYum6yVXs8xgUw3HPCGRpupgtk4pgpSmHZj3vPTUyP1vqRvC1RyWa/5wP/v qAkx09smQ+j4nSC8h9ZDqyq4DjekLHHpRm7xJOL8Bq++fPJ8TTPXTHToV1+OgE1HI0K6 RwIrZPhsZ0VoQwPyR7y8uEExieFv5FwXaHWyBDm7n7i/QG6eDhgYZcLArMzrMqPtpHvX 81ZA== X-Gm-Message-State: AOAM532FiKrf651qZKwobwtC/KCZ54xFpgeja0ZVkSAk7LyHjpYXo/eR AmbRymzLdtrQP8OW0zrqd0Q= X-Google-Smtp-Source: ABdhPJxhZcj8dOW+fGhr79PnegV5U9dr8wELb08QnDI3hmv0FmvTy63rfWxK4cRgioJiJ1StBD0v4w== X-Received: by 2002:a17:906:1fcd:: with SMTP id e13mr7472652ejt.472.1591868448487; Thu, 11 Jun 2020 02:40:48 -0700 (PDT) Received: from gmail.com ([2a03:1b20:3:f011::6d]) by smtp.gmail.com with ESMTPSA id 63sm1265322edy.8.2020.06.11.02.40.47 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 11 Jun 2020 02:40:47 -0700 (PDT) Date: Thu, 11 Jun 2020 11:40:48 +0200 From: Shahab Vahedi To: Simon Marchi Cc: gdb@sourceware.org, Shahab Vahedi Subject: Re: Why enforcing sw_breakpoint_from_kind() implementation in GDBserver targets Message-ID: <20200611094048.GA1270@gmail.com> References: <20200610174702.GA3486@gmail.com> <8f80e486-cca4-819b-7316-329832df985f@simark.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: response_to_simon_1 Content-Disposition: inline In-Reply-To: <8f80e486-cca4-819b-7316-329832df985f@simark.ca> X-Spam-Status: No, score=-10.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 09:40:52 -0000 Hi Simon, The ARC GDB client inserts the breakpoint by writing to memory (the legacy way). With your explanations, I plan to add the Z0 packet support to it. Nevertheless, should it be still necessary to have "sw_breakpoint_from_kind" in GDBserver as a mandatory method? The rest follows: On Wed, Jun 10, 2020 at 11:05:38PM -0400, Simon Marchi wrote: > I don't understand your "This makes sense because we have a setup that looks > like below", because that looks like a standard GDB/GDBserver setup used for > other architectures. I said it makes sense because the first question that pops into mind is "If sw_breakpoint_from_kind should have been mandatory all the time, then how come a debugging session with ARC GDBserver was able to insert breakpoints?". The answer would be because ARC GDB client takes care of it. In ARC case, as you concluded as well, the client asks the GDBserver to write the opcodes to memory. > When a breakpoint is inserted, what's the remote protocol packet used? Is it > Z0, or is it a memory write operation that writes the breakpoint's opcode? Z0 > is the "modern" way that provides more features (like target-side condition > evaluation) and a memory write is the legacy fallback. > sw_breakpoint_from_kind would be used if the Z0 packet was used, to translate > the "kind" into an opcode. Since you claim that sw_breakpoint_from_kind is > not used, I guess that the breakpoint is inserted with a memory write operation. > I'd look into why that is the case. GDB tries Z0 first and falls back to the > memory write if Z0 is not supported, so your GDBserver must not support it for > some reason. I am not sure why this could be the case. I will investigate that. > > Last but not least, one nitpick: Even though I have added the > > implementation of "sw_breakpoint_from_kind", I have never done so for > > "breakpoint_kind_from_pc" or "breakpoint_kind_from_current_state". > > These last two are supposed to provide the "kind" that will be the > > input parameter for "sw_breakpoint_from_kind". Therefore, even if the > > new piece of "sw_breakpoint_from_kind" would be executed, that would be > > problematic. I'm not sure what can be done about this but I think _if_ > > "sw_breakpoint_from_kind" should be mandatory, so are > > "breakpoint_kind_from_pc" and "breakpoint_kind_from_current_state". > > As mentioned above, the input for sw_breakpoint_from_kind can come from > the Z0 packet, so it may make sense to have sw_breakpoint_from_kind without > the others. I am not sure off-hand when the others are used. > > Simon Shahab