From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) by sourceware.org (Postfix) with ESMTPS id 0D4483998831 for ; Wed, 17 Jun 2020 22:20:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0D4483998831 Received: by mail-qk1-x744.google.com with SMTP id j68so332041qkb.10 for ; Wed, 17 Jun 2020 15:20:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rsudAxLq7RhqImfNmisiV8l2t46YVK2F7yItIMc/Ybk=; b=iY8iroY1l2H7oXic3jlWwrJYv92Q+F+cSuErl+o8LyDlfM/qFo9ziiGuJMnbjM+3o4 X+S4mUHRMVZ1c4TZhhULBkWAHtajLWadQpjYOIfvcs9Ndtxxyy4LgHsc+TvLxas6gWGu ThHDKe090QZMzf+10qFij6jvWahx1wuGPCJs6wSWhg8f+LRvxGGEd9L6HrLlKGDpctuz cIlawcrz/X7KLiwlixEGiRyjsS3xq9vEPu7214MC4CoHfnprXvuo11wOsn0CXsuAaE0T TlXHqLvF+vwEhrnov3MeaZpaQUpiWNjYVQze3wo1Y/Iya5tPzhupXDjvL2TkBeVG1lcQ LIkw== X-Gm-Message-State: AOAM530MInWEyHhnHMVh1LYtl3A4N+NinTOOQsoRoz1z6zDeqNhV0qhR HCDtCQO9rkCOOTUPcBTTndP7Og== X-Google-Smtp-Source: ABdhPJxm+NwWTL7yIUyQgdT2FBV6tVUDOn26w9YHILod1kw6ulQS//Hk9h7dg10YnjLsd/qraG2NZA== X-Received: by 2002:ae9:f304:: with SMTP id p4mr860682qkg.149.1592432411541; Wed, 17 Jun 2020 15:20:11 -0700 (PDT) Received: from [192.168.0.185] ([191.34.92.22]) by smtp.gmail.com with ESMTPSA id s17sm1282955qkj.1.2020.06.17.15.20.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Jun 2020 15:20:10 -0700 (PDT) Subject: Re: Why enforcing sw_breakpoint_from_kind() implementation in GDBserver targets To: Shahab Vahedi , "Aktemur, Tankut Baris" Cc: "gdb@sourceware.org" , Simon Marchi , Shahab Vahedi 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> <20200617213106.GA1634@gmail.com> From: Luis Machado Message-ID: Date: Wed, 17 Jun 2020 19:20:06 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200617213106.GA1634@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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 22:20:13 -0000 On 6/17/20 6:31 PM, Shahab Vahedi wrote: > 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(). > I think commit dd373349578df87396bc43e7ab00a1a5ceb16c8b made sw_breakpoint_from_kind required, but under the old C structure, so no compilation errors for whoever didn't implement it. But it seems this doesn't always get used. In fact, it may only be useful to ARM/AArch32 and RISCV. The fact that multiple backends implement it the same way indicates a good candidate for a linux-low implementation that only returns the necessary default bits. Most of the implementations completely ignore the KIND parameter anyway.