From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id O4vPGn09a2BUMgAAWB0awg (envelope-from ) for ; Mon, 05 Apr 2021 12:40:29 -0400 Received: by simark.ca (Postfix, from userid 112) id 5BB071E789; Mon, 5 Apr 2021 12:40:29 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 630BE1E01F for ; Mon, 5 Apr 2021 12:40:28 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D8BFD3857C66; Mon, 5 Apr 2021 16:40:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D8BFD3857C66 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1617640827; bh=2zNwKfT2mzciW4kERWlRUudqTjeBwWRWlIrKueOwHfM=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=PZ5uOlHU6GDuIbnp0rQ5zDU353MyAgcbcAUH508/c92o0BaSkndw4X3OJ97RKsZLz 5UhAVB97x0FuoES4flcuHnpMfPcsmTA6V5sGGkcXcZMgL4tLScBLLf36/omK/dmd5T mzUdh5ftO/Ay8u6TtbMVYka51elitUAy0SSazOto= Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) by sourceware.org (Postfix) with ESMTPS id 72A323857C66 for ; Mon, 5 Apr 2021 16:40:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 72A323857C66 Received: by mail-qt1-x832.google.com with SMTP id u8so8908792qtq.12 for ; Mon, 05 Apr 2021 09:40:24 -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=2zNwKfT2mzciW4kERWlRUudqTjeBwWRWlIrKueOwHfM=; b=EqCozYeNgjD79rtyCisCX2mJFePCCr/E36ElsvPcIlGzTeYg7pwUOIyEUacDDG1rKq SyWV7ssQ8twJaoc+Hx6+cS8Y7EsZRRYX297kA9FJL8I7D7uP+MiBkFaPQaPpOjxtzM7x cQKuuApu2C542g0gHbAifoMwHrj3R5A08R1KyyWWxSlLfEsIY1QIfUVXHuylIFL4vhL/ pOqCX1wGJPRFJ/TJIq9amt6GUv4m6M3OJH2PMO7BX2tsb3QnT6gLjQAYPO3giHSqSazf j/ULcJkBucAL+0re2hqwfRkLj6vm5vTdU9EaIPqRGFcEzh1gUDskgeJ/O5IXrwrU19dp X79Q== X-Gm-Message-State: AOAM533D/MggJlzcAgOJKm3vp5NgqkYUujQeGuBWPIzD+7m3XomEZUfH d9Rz+1FmGiZOEv6FYeAVM9veG+hsM14igA== X-Google-Smtp-Source: ABdhPJwf2yanwReQ9QUwrCyUptiII8qggofAKS/1NcmsLJ1XPXwBzYI0i21R+0CrZ8Xyqw3A1DOpTw== X-Received: by 2002:ac8:7c8d:: with SMTP id y13mr22385717qtv.294.1617640823944; Mon, 05 Apr 2021 09:40:23 -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 k126sm13935605qkb.4.2021.04.05.09.40.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Apr 2021 09:40:23 -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> Message-ID: <51cfbb5b-ed10-c9d8-8dc3-81b3da496022@linaro.org> Date: Mon, 5 Apr 2021 13:40:20 -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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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: , From: Luis Machado via Gdb Reply-To: Luis Machado Errors-To: gdb-bounces@sourceware.org Sender: "Gdb" 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 >>> >>> > -- > > *Zied Guermazi* > founder > > Trande UG > Leuschnerstraße 2 > 69469 Weinheim/Germany > > Mobile: +491722645127 > mailto:zied.guermazi@trande.de > > *Trande UG* > Leuschnerstraße 2, D-69469 Weinheim; Telefon: +491722645127 > Sitz der Gesellschaft: Weinheim- Registergericht: AG Mannheim HRB 736209 > - Geschäftsführung: Zied Guermazi > > *Confidentiality Note* > This message is intended only for the use of the named recipient(s) and > may contain confidential and/or privileged information. If you are not > the intended recipient, please contact the sender and delete the > message. Any unauthorized use of the information contained in this > message is prohibited. > >