From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) by sourceware.org (Postfix) with ESMTPS id 4340F384640D for ; Mon, 5 Apr 2021 22:04:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4340F384640D Received: by mail-qk1-x733.google.com with SMTP id c3so13028892qkc.5 for ; Mon, 05 Apr 2021 15:04:55 -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:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=lE5u1WEmwJUrPHMOHnELijvdEbYT2bXIyhfth+8607g=; b=Hq5kb7uNr+mbJPffCYBhKPv/Wmtk2Khe1oJTsoMOBjinR8sBZukDGqwkA67y44jEnA +t6cEWHfsBXO74ULpi1VFVKKXUYbBceUFqrJLhXpF5MNVnbnzxpDkj+NKdFxzIM7+lOu zstnWjHN7wKMFwzc5e8eJK5pEVsag3GmHe0siRtVkQOaIkIEYFlZrSSqwtUmmM6o5yji hP1ob8ChCGbbQ/YdjM+46RUCGluCn2t1b+oQUhRnH45627qh1RTs8pFtsAh4q9g7GJdk 4M9QUaWLWH20wlYJmw6VDA/tLGZIExRuoXoFAGF7BH5oWmw0KdiMuYiLbojaV2X7Gr4L QOkg== X-Gm-Message-State: AOAM530VU2fexFcY+AuIUuO2J4j7zTvKD7qnOTSQs/WTpEV/QOtcWDog 0EvBc3l/KPqmWBODtcwfMFvhDctjmnGiWg== X-Google-Smtp-Source: ABdhPJx484Q2/1qC41MF7S+PAQ7qhpiP5LyjueQtdNlr39+czFaeauHa9+ZpCGBzKMBov49q6dZFWw== X-Received: by 2002:a37:a647:: with SMTP id p68mr26223883qke.189.1617660294734; Mon, 05 Apr 2021 15:04:54 -0700 (PDT) Received: from ?IPv6:2804:7f0:4841:2841:2863:21b6:ccec:53b6? ([2804:7f0:4841:2841:2863:21b6:ccec:53b6]) by smtp.gmail.com with ESMTPSA id x14sm14226233qkx.112.2021.04.05.15.04.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Apr 2021 15:04:54 -0700 (PDT) Subject: Re: A lean way for getting the size of the instruction at a given address To: Zied Guermazi , "gdb@sourceware.org" References: <295a186e-0dd9-fb96-671a-3df0a5611dd9@trande.de> <442482d9-31bd-8101-38f0-fb7c7763e61c@trande.de> <476fcf13-8782-a69f-f43b-069497ba7e3b@linaro.org> <51cfbb5b-ed10-c9d8-8dc3-81b3da496022@linaro.org> <72e584f8-2cf6-0bfa-882d-a1ba21a43931@trande.de> From: Luis Machado Message-ID: <0f2147c8-770d-5cb2-f415-8549b7192b36@linaro.org> Date: Mon, 5 Apr 2021 19:04:51 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <72e584f8-2cf6-0bfa-882d-a1ba21a43931@trande.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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: Mon, 05 Apr 2021 22:04:57 -0000 Hi Zied, On 4/5/21 6:47 PM, Zied Guermazi wrote: > hi Luis, > > thanks for your support. To experiment the impact of removing the > printing of the instruction on the overall performance, I commented out > setting and using the print function pointer in print_insn (bfd_vma pc, > struct disassemble_info *info, bfd_boolean little) in opcodes/arm-dis.c, > and the result was very interesting: The time needed to process the > traces dropped down from 12 minutes to 34 seconds for 64 MB of traces. That is quite a bottleneck! I think this code path isn't exercised often. > > now that we have a proof that the bottleneck was printing, we can think > about a way to provide a clean implementation. I agree. A faster implementation of this particular function would be nice to have. It may even improve some other code paths that use this information. > > Kind Regards > > Zied Guermazi > > > On 05.04.21 18:40, Luis Machado wrote: >> On 4/5/21 1:17 PM, Zied Guermazi wrote: >>> hi Luis >>> >>> A new member function in "class gdb_disassembler" to calculate the >>> instruction length only will be a good solution. In fact a big >>> overhead is added by the printing of instruction disassembly, which >>> is not needed at all. On aarch64, the decoder is optimized to issue >>> many instruction in one trace element, and here calculating the size >>> consumes more than 80% of the time. On arm, the decoder issues one >>> instruction after another and here getting the size consumes 50% of >>> the time. Considering the amount of traces this can sum up to a dozen >>> of minutes in some cases (64MB of traces) >> >> Indeed, that doesn't sound good. >> >>> >>> Calculating the instruction size per se, on arm is a "rapid" >>> operation and consists of checking few bits in the opcode. So the >>> time can be drastically decreased by having a function to calculate >>> the size only. >>> >>> >>> gdb_print_insn can be then changed as following (pseudo code): >>> >>> int >>> gdb_print_insn (struct gdbarch *gdbarch, CORE_ADDR memaddr, >>>          struct ui_file *stream, int *branch_delay_insns) >>> { >>> >>>    gdb_disassembler di (gdbarch, stream); >>> >>>    if ( di.get_insn_size != 0) >>> >>>     return di.get_insn_size(memaddr); >>> >>>    else >>> >>>     return di.print_insn (memaddr, branch_delay_insns); >>> } >>> >>> Is there a function in aarch64-tdep or arm-tdep doing job of >>> disassembly ( the lower layer handling the opcode)? are we relaying >>> on the bfd library for it? can someone give me a hint of where to >>> find those functions? >> >> The gdbarch hooks in arm-tdep.c (gdb_print_insn_arm) and >> aarch64-tdep.c (aarch64_gdb_print_insn) are more like helper functions >> and do some initial setup, but the code to disassemble lies in >> opcodes/arm-dis.c (print_insn) and opcodes/aarch64-dis.c >> (print_insn_aarch64). >> >> If you go with the route of changing "class gdb_disassembler", then >> you'll probably need to touch binutils/opcodes. >> >> If you decide to have a gdbarch hook (in arm-tdep/aarch64-tdep), then >> you only need to change GDB. >>> >>> >>> Kind Regards >>> >>> Zied Guermazi >>> >>> >>> On 05.04.21 15:01, Luis Machado wrote: >>>> Hi Zied, >>>> >>>> On 4/4/21 4:59 AM, Zied Guermazi wrote: >>>>> hi >>>>> >>>>> I need to get the size of the instruction at a given address. I am >>>>> currently using gdb_insn_length (struct gdbarch *gdbarch, CORE_ADDR >>>>> addr) which calls gdb_print_insn (struct gdbarch *gdbarch, >>>>> CORE_ADDR memaddr, struct ui_file *stream, int >>>>> *branch_delay_insns). and this is consuming a huge time, >>>>> considering that this is used in branch tracing and this gets >>>>> repeated up to few millions times. >>>>> >>>>> >>>>> Is there a lean way for getting the size of the instruction at a >>>>> given address, I am using it for aarch64 and arm targets. >>>> >>>> At the moment I don't think there is an optimal solution for this. >>>> The instruction length is calculated as part of the disassemble >>>> process, and is tied to the function that prints instructions. >>>> >>>> One way to speed things up is to have a new member function in >>>> "class gdb_disassembler" to calculate the instruction length only. >>>> >>>> Another way is to have a new gdbarch hook that calculates the size >>>> of an instruction based on the current PC, mapping symbols etc. >>>> >>>>> >>>>> Kind Regards >>>>> >>>>> Zied Guermazi >>>>> >>>>> >>> >>> >