From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) by sourceware.org (Postfix) with ESMTPS id CC05039D9E40 for ; Wed, 17 Jun 2020 21:31:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CC05039D9E40 Received: by mail-ed1-x544.google.com with SMTP id c35so3256004edf.5 for ; Wed, 17 Jun 2020 14:31:06 -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=BUCJXG6LOLgRyQuN+odm31+Etn9V7J7bK060KDKvIuI=; b=sDpCOaJ3Zv3OooXhCccwa6nB2NbZvFvu3/peCoaPdn0oKTwkBQKvZ2wUa89YuAgRzx qwt6xeUrRJylYztE7K6a4zexXP5sR4WH/qlBRNM8A73UPLC5jS77AYClybBXPzZjCnky 1my6hHyGIskQkkvyJy3j8yFzzjzGRGzMXNZGzUVx1Ja85mY/1M2KOBF3HgEnDz6WR8Nw o4UyzPErQ5/zh60BtIXv/LLLSX6TA/l2RgidlIO4f9xuXOYtEk115X+wi8KfWeAEckPK I3Gt6PUatZXvxKDanDNOmul0OSnrIkHzo57KYmPuFTqMi36agLVfkqG/3uPHNmOs9S2Z 4pJA== X-Gm-Message-State: AOAM531GnOgAa3aDt9v6/+0rY4J91MQjquROa8jUfNhCwEv6D3dLbvGS +XxruZUHBc988OV9QJEbJgw= X-Google-Smtp-Source: ABdhPJzrARruHXN4rABoEvrxdvti6pLScYcUC3bbxaeBaiIcAuvIVgc8ENyFqknHjJCOU+13NIz17Q== X-Received: by 2002:a05:6402:8d8:: with SMTP id d24mr1059575edz.287.1592429465946; Wed, 17 Jun 2020 14:31:05 -0700 (PDT) Received: from gmail.com ([2a03:1b20:3:f011::6d]) by smtp.gmail.com with ESMTPSA id dn17sm544692edb.26.2020.06.17.14.31.04 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 17 Jun 2020 14:31:05 -0700 (PDT) Date: Wed, 17 Jun 2020 23:31:06 +0200 From: Shahab Vahedi To: "Aktemur, Tankut Baris" Cc: "gdb@sourceware.org" , Simon Marchi , Luis Machado , Shahab Vahedi Subject: Re: Why enforcing sw_breakpoint_from_kind() implementation in GDBserver targets Message-ID: <20200617213106.GA1634@gmail.com> References: <20200610174702.GA3486@gmail.com> <8f80e486-cca4-819b-7316-329832df985f@simark.ca> <20200611094048.GA1270@gmail.com> <07362b1e-3b9b-a858-ce7a-9a27daff511a@linaro.org> <20200611110053.GD1270@gmail.com> <20200611114418.GE1270@gmail.com> <20200615103913.GA1816@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Description: baris_response Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-8.0 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: Wed, 17 Jun 2020 21:31:08 -0000 Hi Baris, Sorry for my late reply and thank you again for your thorough response. On Tue, Jun 16, 2020 at 01:15:29PM +0000, Aktemur, Tankut Baris wrote: > 1. In GDB 9 (i.e. before C++'ification of gdbserver's target definition), > the base linux target implemented the "sw_breakpoint_from_kind" target op > to directly delegate to "sw_breakpoint_from_kind" of the linux low target. > It asserted that the low target's "sw_breakpoint_from_kind" function pointer > is non-null. And this is how the ARC port at the time looked like: gdb/gdbserver/linux-arc-low.c [1]: ... struct linux_target_ops the_low_target = { arc_arch_setup, arc_regs_info, arc_cannot_fetch_register, arc_cannot_store_register, NULL, /* fetch_register */ linux_get_pc_32bit, linux_set_pc_32bit, NULL, /* breakpoint_kind_from_pc */ NULL, /* sw_breakpoint_from_kind */ NULL, /* get_next_pcs */ 0, /* decr_pc_after_break */ arc_breakpoint_at, }; ... This did not hit the assert in base linux implementation, since "linux_sw_breakpoint_from_kind" was never executed. It's because the GDB client was writing the breakpoint opcodes to the address through gdbserver while bypassing sw_breakpoint_from_kind(). > As far as I understand, there is a certain control flow and a combination > of (un)supported features in the ARC port with which the "sw_breakpoint_from_kind" > target op is not invoked. I'm not sure what this flow or feature combination is. I guess what I explained above should be the case. I do not know the exact control flow that led/leads to this though. > Just out of curiosity, is there a specific reason why you want to avoid implementing > the "sw_breakpoint_from_kind" target op? No, there is no reason that I might be against it. I brought this whole thing up because I noticed ARC did not have sw_breakpoint_from_kind implemented and it was working fine. Even after I implemented the pure virtual method [2], it does not get executed (I put an assert in a temporary implementation as an experiment). So it seemed like an unnecessary constraint for compilation. If we want to deprecate how ARC inserts breakpoints (GDB client writing the opcode through GDBserver) then that is fine [3]. If not, then implementing sw_breakpoint_from_kind() shouldn't be mandatory. I just wanted to make sure that this message is conveyed. That's all :) For the record, I plan to change ARC's behavior to really use sw_breakpoint_from_kind(), but that is not the purpose of this email. Shahab [1] https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb/blob/arc-2019.09-gdb/gdb/gdbserver/linux-arc-low.c#L300 [2] https://github.com/foss-for-synopsys-dwc-arc-processors/binutils-gdb/blob/arc-2020.09/gdbserver/linux-arc-low.cc#L350 [3] Please keep in mind that if deprecation is wanted, yet still nothing is stopping ARC (and the likes) from bypassing sw_breakpoint_from_kind().