From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 2C85A385381D for ; Tue, 4 Oct 2022 08:46:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2C85A385381D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664873164; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4ZNf+yWBSrXti0JuYHq7xt8VPMmamxMuhwDdgtYlzaE=; b=OWcp0VPCJsdDQe3d8OJPf5PY0+Draq3FWMtTtNnvhDWo4n3xCOCjtJMLtj4hp7kUT1COQ0 PBnuh9f/0AYOqh2cHMqRkgKn2Fz/DadDTzVPAedk5NLzaHyuCv6685FadwDLMe8JKoGmLM 1Zjv1ejCygVYGBEh6wfMIJei8Y8n/h4= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-190-L6LuwGogOnOa3o1SiqPF9g-1; Tue, 04 Oct 2022 04:46:03 -0400 X-MC-Unique: L6LuwGogOnOa3o1SiqPF9g-1 Received: by mail-wm1-f70.google.com with SMTP id l15-20020a05600c4f0f00b003b4bec80edbso7533756wmq.9 for ; Tue, 04 Oct 2022 01:46:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date; bh=4ZNf+yWBSrXti0JuYHq7xt8VPMmamxMuhwDdgtYlzaE=; b=xhkq2MTnKWVi755WnJ6fGn8wopbG8cG5vZsy9g8Y1U804SQ+BaBW9lROZREj1HEPdA 6RDuXoyMw1URfmSPJ8wCaNHdwqBtH8DZP3vzeXz0xHCUne5DgyEpfrIJSc9JeAgKNOCu VBSkj+yiXP8JSe06U1uyOfEaD+pwziXArSBgXto2GY2ViGk/KQoaa6pIi2HFig/y9NI0 5XW7nGSQOtAOZMYpwv59OY2Ixlx/gEpxw0/HDdggBxdyQL77Kzz7pUbpvqRf1THsBqwA FBaRXUNLdT9LZfSdqK5FnZUWka6C0nbfay+2EUQfDDIZc3F0qmL0dUw/5z+8XOdg3yW/ 3ejA== X-Gm-Message-State: ACrzQf1AwjrlyCDg7RoTJEv7qKfLCATJ4Dqw9ambKcngmI7qs0o10Kko knPo43PQrsC4bl+W7mUbahB7F8Ag/HQ9fGqj+wXJ2zi8b9dj1m5e1xzhfBbFq6rIByzuhEOq7pK oyrzrsGpeNCTekQ5utg== X-Received: by 2002:a5d:6d0a:0:b0:22e:3f3a:5cdf with SMTP id e10-20020a5d6d0a000000b0022e3f3a5cdfmr4374787wrq.156.1664873162649; Tue, 04 Oct 2022 01:46:02 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6bBMy4Wf8dwHmYAs1GuH8Gha9u85fcjr7jT8qnIMwHemb0HUxsOY+9xxKx1o6PzV/zxbJm8A== X-Received: by 2002:a5d:6d0a:0:b0:22e:3f3a:5cdf with SMTP id e10-20020a5d6d0a000000b0022e3f3a5cdfmr4374768wrq.156.1664873162361; Tue, 04 Oct 2022 01:46:02 -0700 (PDT) Received: from localhost (52.72.115.87.dyn.plus.net. [87.115.72.52]) by smtp.gmail.com with ESMTPSA id bn13-20020a056000060d00b0022e35e34420sm8559170wrb.18.2022.10.04.01.46.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Oct 2022 01:46:01 -0700 (PDT) From: Andrew Burgess To: Palmer Dabbelt Cc: binutils@sourceware.org, research_trasio@irq.a4lg.com, nelson@rivosinc.com, kito.cheng@sifive.com, binutils@sourceware.org Subject: Re: [PATCH v2 0/6] RISC-V: Fix disassembler types and styles In-Reply-To: References: Date: Tue, 04 Oct 2022 09:46:01 +0100 Message-ID: <8735c4genq.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Palmer Dabbelt writes: > On Mon, 03 Oct 2022 02:59:18 PDT (-0700), aburgess@redhat.com wrote: >> Tsukasa OI via Binutils writes: >> >>> Hello, >>> >>> This patchset fixes various typing and styling errors on the RISC-V >>> disassembler. >> >> I can't approve binutils patches. >> >> I've taken a look through this series, and other than the minor typo I >> spotted, this all looks good to me. > > My worry with these things is that it's sort of a grey area in terms of > what our stable user interface is: there's definitely folks who try and > parse the text output of tools like objdump and changing anything risks > breaking that. IMO that's too strict of a stable interface to keep > around as it pretty much prevents us from fixing any disassembly > weirdness, but I'm not sure if that's what other ports do and I don't > want to make a mess by breaking users' expectations here. I guess we'd want to consider these things on a case-by-case basis. I'm struggling to think of a situation where we wouldn't want to fix something in the disassembler output if it was wrong over leaving it incorrect because someone, somewhere, might have a script that depends on the broken output. But unless I've missed something, I don't think this series makes any changes to the output other than styling, and I don't think a script that's trying to parse the disassembler output should be running with styling switched on.... ...or if they are, maybe because they want to figure out which bits of the text are which, then surely they'd welcome these fixes? > That said, as far as I can tell the only user-visible change here is to > print some bits with the correct syntax coloring in GDB. And in objdump, which also styles its output by default now when the output is going to a tty. Any scripts that capture objdump output should see no changes with this series. The styling is pretty new, and I knew when I added it there were going to be mistakes with things styled incorrectly. I was basically relying on getting something in that was not terrible, and then relying on folk like Tsukasa to come along and fix my mistakes. IMHO, any script that relies on a fixed styling is a bad script. I'd probably go further, and say that any script that can't handle minor changes in the disassembly output at all is a bad script, but without seeing every case that might be a little harsh. Anyway, FWIW, I think we should for sure approve this series. Thanks, Andrew > Seems pretty > straight-forward to say anything users can't rely on parsing syntax > highlighting colors being a stable interface, so maybe we can just punt > on the grey area for now ;) > >> Thanks for doing this. > > Yep. These LGTM, but I'm still kind of buried thanks to the > a few weeks of conference->COVID. They're probably fine, but hopefully > Nelson has the time to chime in -- if not I'll leave them in the queue. > > Thanks! > >> >> Andrew >> >> >> >>> >>> Previous Patchsets: >>> (2022-07-13) >>> (2022-08-03) >>> Tracker on GitHub: >>> >>> >>> >>> [Changes: v1 -> v2] >>> >>> - Added PATCH 5-6/6 after T-Head extensions are merged. >>> - Slightly improved the commit messages? >>> >>> >>> [Styling] >>> - Print real immediates with the `immediate' style (PATCH 1/6) >>> - Print comma and tabs with the `text' style (PATCH 4/6) >>> - Print T-Head literal operand with `immediate' style (PATCH 6/6) >>> [Typing on printf] >>> - Fix wrong type for "%x" format specifier (PATCH 2/6) >>> - Fix minor but various typing issues on T-Head immediates (PATCH 5/6) >>> [Small Optimization] >>> - Use smallest portable types possible to print (PATCH 3/6) >>> >>> Thanks, >>> Tsukasa >>> >>> >>> >>> >>> Tsukasa OI (6): >>> RISC-V: Fix immediates to have "immediate" style >>> RISC-V: Fix printf argument types corresponding %x >>> RISC-V: Optimize riscv_disassemble_data printf >>> RISC-V: Print comma and tabs as the "text" style >>> RISC-V: Fix T-Head immediate types on printing >>> RISC-V: Print XTheadMemPair literal as "immediate" >>> >>> opcodes/riscv-dis.c | 71 +++++++++++++++++++++++++-------------------- >>> 1 file changed, 39 insertions(+), 32 deletions(-) >>> >>> >>> base-commit: c21736aed1d4877e090df60362413669dbdc391d >>> -- >>> 2.34.1