From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=lXnp=6F=rivosinc.com=nelson@sourceware.org>
Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com [IPv6:2001:4860:4864:20::32])
	by sourceware.org (Postfix) with ESMTPS id 839DC3858284
	for <binutils@sourceware.org>; Thu,  9 Feb 2023 02:21:52 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 839DC3858284
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com
Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-16a291b16bfso915523fac.7
        for <binutils@sourceware.org>; Wed, 08 Feb 2023 18:21:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=rivosinc-com.20210112.gappssmtp.com; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=Z0ovDopGRSNjw6HCnbIDd9+bqR6Z7szA/rauGaTT63A=;
        b=VA1exWhTJzyvTPO5qAkBFdnfaZ23zUFoHUORckEGv21XiuggNbW8Du0SpOE0jWZUl2
         2OnB/QbmgtMX/QZHx/F3szz2dEb1GOxbZGZ2Xtudj4QRjzYieD2QSE40jF2XP8U1I1Af
         A7OPLo5D9/lALswU6MXwtJGX0cR1Z5N10fWltVqhPzyoY/DCYnUFHzVxDARfILvt5ARE
         4nWu4AeUSV8wpCtEYSSnGPmzH5MqnJzrFK4UUJzLd6CPi4YCMPY/sZMr+Kavvo4sx77A
         AH3YFCVK5vcii862AYI8cEzqX3S58duoqmIjbk/wwqnJc5ADpGhH45VR5HoE5cD9vlCE
         muHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Z0ovDopGRSNjw6HCnbIDd9+bqR6Z7szA/rauGaTT63A=;
        b=ZPvWRUIKIkds66uWi1WLvnAompeRNLIwpdiQqbO4CvXouXRfH5re3Sx+sQXUvcnLNz
         5sPt6WkR+p1La5K3s3e/Z+I9AmRFIKi2OtzGNPlFv29B/IkcrtshuswQShDzYVZfUH7P
         10eyT8AZqpj9aAju0YG8nNeDZdhBopMgdFdozcZo/U6xt12d6izXrRd0SOrg+DOaKSjQ
         3sl04PTZH72J58vBT1a/Z2Dj/48nKFqvUMDgrP+dFxT1p/tjhKGaw8MSoW89xW4GrCRR
         JSJ1oi5wCSkwvCbOUm05wtCLDI06B/u97F6jShllwtAbQSMNXk5FNQAjAdgOIguTzifT
         uCpg==
X-Gm-Message-State: AO0yUKVAL8uQsvT87W9KdcVnZv1OlvrQg4v8edxHX4ybSBiDKTGLw/xH
	w4uE5xam7GiAE9q4oFAzE+B9bncXlYytMLHxgM64nA==
X-Google-Smtp-Source: AK7set+tO9ECYJVB62xNHZy/IWR48zulZacGIK6d4adnD4v2KC+W9xfVCjugDg/nCjIqfof5Y8Sui89XL3lLbQSmgNM=
X-Received: by 2002:a05:6870:a68c:b0:16a:4df8:94e5 with SMTP id
 i12-20020a056870a68c00b0016a4df894e5mr857089oam.201.1675909311117; Wed, 08
 Feb 2023 18:21:51 -0800 (PST)
MIME-Version: 1.0
References: <DS7PR12MB57659139C1D9EA568403722DCBDB9@DS7PR12MB5765.namprd12.prod.outlook.com>
 <alpine.DEB.2.20.2302071415340.7841@tpp.orcam.me.uk> <53fa13a4-9828-94a7-b639-991ced5da25b@suse.com>
 <alpine.DEB.2.20.2302071601070.7841@tpp.orcam.me.uk>
In-Reply-To: <alpine.DEB.2.20.2302071601070.7841@tpp.orcam.me.uk>
From: Nelson Chu <nelson@rivosinc.com>
Date: Thu, 9 Feb 2023 10:21:40 +0800
Message-ID: <CAPpQWtDFyS77M8AnpKQ20YEW2=Ct+LvafUxg_QJaCgUxaH=CXw@mail.gmail.com>
Subject: Re: objdump riscv: Stop disassembling addi rd, rs, 0 with a
 relocation as mv rd, rs?
To: "Maciej W. Rozycki" <macro@embecosm.com>
Cc: Jan Beulich <jbeulich@suse.com>, binutils@sourceware.org, Fangrui Song <i@maskray.me>, 
	Andreas Schwab <schwab@suse.de>, Jim Wilson <jim.wilson.gcc@gmail.com>, 
	Palmer Dabbelt <palmer@rivosinc.com>, Andrew Waterman <andrew@sifive.com>, 
	Kito Cheng <kito.cheng@sifive.com>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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: <binutils.sourceware.org>

Seems most of the experts agree with this good idea.  Besides, in the
other thread discussion, Palmer and I also like it,  so I created a
bugzilla to trace this,
https://sourceware.org/bugzilla/show_bug.cgi?id=30099

Thanks
Nelson

On Wed, Feb 8, 2023 at 12:05 AM Maciej W. Rozycki <macro@embecosm.com> wrote:
>
> On Tue, 7 Feb 2023, Jan Beulich wrote:
>
> > >  However it may be quite hard to implement given how the GNU disassembler
> > > has been structured; most easily probably by setting the `no_aliases' flag
> > > temporarily for any instruction seen with a relocation attached.  This
> > > could have undesired consequences elsewhere though and would most likely
> > > make Jan unhappy who wants to see aliases in disassembly rather than
> > > machine instruction mnemonics with the immediate forms.
> > >
> > >  So instead we may need another flag for the opcode table, such as
> > > INSN_NORELOC, which would exclude the given entry for instructions with
> > > any relocation attached; I think this would be the cleanest approach,
> > > though maybe a little bit more involving implementation-wise.
> >
> > Could we get away with simply skipping aliases in general when there's a
> > relocation for an insn?
>
>  I think it would be unreasonably inconsistent though.  Also I think we do
> want to keep the `*z' branch forms in disassembly.
>
>   Maciej