From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 56B9B385DC0A for ; Thu, 11 Jun 2020 03:05:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 56B9B385DC0A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.11] (173-246-6-90.qc.cable.ebox.net [173.246.6.90]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id F38971E791; Wed, 10 Jun 2020 23:05:38 -0400 (EDT) Subject: Re: Why enforcing sw_breakpoint_from_kind() implementation in GDBserver targets To: Shahab Vahedi , gdb@sourceware.org Cc: Shahab Vahedi References: <20200610174702.GA3486@gmail.com> From: Simon Marchi Message-ID: <8f80e486-cca4-819b-7316-329832df985f@simark.ca> Date: Wed, 10 Jun 2020 23:05:38 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200610174702.GA3486@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, KAM_ASCII_DIVIDERS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no 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 03:05:40 -0000 On 2020-06-10 1:47 p.m., Shahab Vahedi via Gdb wrote: > Now, it has to provide the implementation for "sw_breakpoint_from_kind". > That is not the whole story. I also noticed that this piece of newly > implemented code never gets executed. This makes sense because we have > a setup that looks like below (both entities are running inside > GNU/Linux): > > ,------------------------------------------------. > | ARC GDB client on x86 machine (cross debugger) | > `------------------------------------------------' > /\ > || > remote debugging > || > \/ > ,------------------------------------------------. > | ARC GDBserver on ARC board (native server) | > `------------------------------------------------' > > It is the "ARC GDB client" that inserts the breakpoint. That has always > been the case. Else, it would be impossible to break while debugging > with GDBserver in older implementation (before rebase). It is worth > mentioning the "ARC GDB client" does have the "sw_breakpoint_from_kind" > implemented []. 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. 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. > 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