From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by sourceware.org (Postfix) with ESMTPS id 4D1923858D33 for ; Mon, 26 Jun 2023 22:00:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4D1923858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-4f8775126d3so5124222e87.1 for ; Mon, 26 Jun 2023 15:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687816812; x=1690408812; h=content-transfer-encoding:in-reply-to:from:cc:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=fxvptG3guqi8TLpQgG7JGE9utUruo61MX9ILSldEL1o=; b=HloYeusXsu3/Qt0nCTr2yoUZV8Qap8yxxBU8mI68n3d9naT5PFGAw5DiI+27NTSWiC FZ5AehSbj++bP2le1h9tXHcCkwqHdGM88Apfs+Ar7XRMA48N1V4yg6Ysoe2apIwcjr8J 9rMJRZtuj0sacv18GuVecr1cjkBRcLlowwFfPrNZ4GCqSpkdxvd+C0aBgRwwIEism966 I19yB9pYOxUTZUws8OxXx+50W6HFrXEiceQPDa7v/hN4f2GZ6c9s4npIjKbVsb2Gdkst B3/bQL+b5vBWAtAP/ESMa8xX5GgaAEjk3rf1CzMr6oxCE75Fs3J+WZouLlorSmBm0aAF 0BSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687816812; x=1690408812; h=content-transfer-encoding:in-reply-to:from:cc:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fxvptG3guqi8TLpQgG7JGE9utUruo61MX9ILSldEL1o=; b=H73ViA2sDHNzz9qzMnYUpTi9tjFXda/AIzma2QSQTJnI0xUDB6n6wK9ZxFnAeo+/Tq R2mHfiMQq2EPz0fwC2PWSaQau0Oa7QBsWEj0XbpZfokHZIfAu6l+NoqxWmg9xLDKOuil gAQWBP3KfhffswmHwhFqFLlyNq6+H8fHhQ92YQfwVUq/WjLfyuxyXskRvKUCD40tzT5V 1mF5iIVA2ZXPf3k2wnEHyV9dvp9p5NqpmHaweJin7nSDZeGyWy5SGc6Xh/ZHYjFvFumg QXf4vmqeJfeB83sJGLOlJzcKvrSKyBbZ5gFb/Lx+gvtX9nzUVhJsgmxnYRQRpko7Qk21 OCFw== X-Gm-Message-State: AC+VfDwqrRwncWwmmJnkCCrDrW0BV01aEJtkgNE6IFAJIsVc0olI95G1 vJDqJfeq2GRod2NIlU/iEM/mASpuP0s= X-Google-Smtp-Source: ACHHUZ50oLd6ifCi9xNAXCYzHXROvem3EFogHCaCc7LA/FFZuetv70bfe3RJEz7O8Sov/rmn7EeEow== X-Received: by 2002:a05:6512:3a96:b0:4fb:7642:88d3 with SMTP id q22-20020a0565123a9600b004fb764288d3mr3130005lfu.27.1687816811373; Mon, 26 Jun 2023 15:00:11 -0700 (PDT) Received: from [192.168.1.20] (78-73-77-63-no2450.tbcn.telia.com. [78.73.77.63]) by smtp.gmail.com with ESMTPSA id h4-20020a197004000000b004fae1d35098sm971923lfc.81.2023.06.26.15.00.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jun 2023 15:00:10 -0700 (PDT) Message-ID: <0e7435f3-ce8b-15ae-9e4c-ecda1386bea7@gmail.com> Date: Tue, 27 Jun 2023 00:00:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v1] gdb/DAP Fix disassemble bug To: Tom Tromey References: <20230626161654.207687-1-simon.farre.cx@gmail.com> <87cz1ixecl.fsf@tromey.com> Content-Language: en-US Cc: gdb-patches@sourceware.org From: Simon Farre In-Reply-To: <87cz1ixecl.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 6/26/23 20:34, Tom Tromey wrote: >>>>>> "Simon" == Simon Farre via Gdb-patches writes: > Simon> Fixes disassembleRequest > Simon> The field instructionOffset can be negative. Previous patch made it so > Simon> that sometimes the request got calculated to 0 instructions, when it > Simon> meant to retrieve disasm for -50 to 0 (current position). > > I don't think this will work correctly, because this isn't counting by > instruction but rather by byte. > > instructionOffset is defined in terms of instructions: > > Offset (in instructions) to be applied after the byte offset (if any) > before disassembling. Can be negative. > > I must have missed the "negative" note, or maybe I just ignored it > without documenting that -- since I wonder how it can possibly work. it > seems to me that on architectures with variable length instructions, you > can't really disassemble in "reverse" like that. > > I guess one idea would be to back up to the previous symbol and start > disassembling from there. I feel like the TUI did this, though, and ran > into all kinds of weird corner cases. > > Simon> - for elt in arch.disassemble(pc, count=total_count)[skip_insns:]: > > I notice now that the current code also neglects this part of the spec: > > * An adapter must return exactly this number of instructions - any > * unavailable instructions should be replaced with an implementation-defined > * 'invalid instruction' value. > > Tom Then perhaps we should just ignore any and all offsets and *just* care about count and produce current addr + N instructions and resolve "invalid value" for the rest.