From: Tsukasa OI <research_trasio@irq.a4lg.com>
To: shihua@iscas.ac.cn
Cc: Nelson Chu <nelson@rivosinc.com>, binutils@sourceware.org
Subject: Re: [PATCH 0/1] RISC-V: Minor fix to the 'Ztso' extension support
Date: Wed, 21 Sep 2022 19:14:24 +0900 [thread overview]
Message-ID: <aaa59c6a-2729-3bff-50e4-45fbf840752b@irq.a4lg.com> (raw)
In-Reply-To: <5f6cebd7.98e3.1835f77a59d.Coremail.shihua@iscas.ac.cn>
On 2022/09/21 18:53, shihua@iscas.ac.cn wrote:
> Hi,Tsukasa OI
> In patch V4 ( https://sourceware.org/pipermail/binutils/2022-September/122962.html ), I removed support tso for the .option directive. So I think it's not necessary to add this.
> Thanks，
> Shihua
I don't agree that theory. riscv_set_options.tso might not be
absolutely necessary (as Nelson pointed out) but EF_RISCV_TSO handling
should remain.
The option variable for RVC (riscv_set_options.rvc) is necessary because
the assembler needs some decisions based on the "current" status of
whether the 'C' extension is enabled. That's different from
riscv_set_options.tso (that is removed).
However, for ELF flags, things are a bit different. If RVC ('C'
extension) is used *somewhere* in the object file, the whole object file
must depend on RVC in some way. Likewise, if TSO ('Ztso' extension) is
used *somewhere* in the object file, the whole object file must depend
on TSO in some way.
In either cases, we should check whether related extension is enabled
somewhere in the object file and set corresponding ELF flags.
There are two cases:
1. When we parse "initial" architecture
('C' and 'Ztso')
2. When the architecture is changed via ".option arch"
('C' only!?)
So, my conclusion is, riscv_set_options.tso handling can be removed but
EF_RISCV_TSO handling in ".option arch" cannot (as long as we support TSO).
Regards,
Tsukasa
>
>
> > -----原始邮件-----
> > 发件人: "Tsukasa OI" <research_trasio@irq.a4lg.com>
> > 发送时间: 2022-09-21 14:40:42 (星期三)
> > 收件人: "Tsukasa OI" <research_trasio@irq.a4lg.com>, "Nelson Chu" <nelson@rivosinc.com>, "Shihua LIAO" <shihua@iscas.ac.cn>
> > 抄送: binutils@sourceware.org
> > 主题: [PATCH 0/1] RISC-V: Minor fix to the 'Ztso' extension support
> >
> > Hi all,
> >
> > I think Shihua could have missed my review 2:
> > <https: sourceware.org="" pipermail="" binutils="" 2022-september="" 122916.html="">
> > (see near the end of my e-mail starting with "Other than that,").
> >
> > Currently, it sets EF_RISCV_TSO ELF flag when initial ISA string contains
> > the 'Ztso' extension. However, GAS has a way to update the ISA string:
> > ".option arch".
> >
> > When the architecture is updated by ".option arch", EF_RISCV_RVC ELF flag
> > is set when the 'C' extension is detected. Analogously, this patchset sets
> > the EF_RISCV_TSO when the 'Ztso' extension is detected.
> >
> > With this patch, the 'Ztso' extension support will be complete.
> >
> > Thanks,
> >
> >
> >
> >
> > Tsukasa OI (1):
> > RISC-V: Set EF_RISCV_TSO also on .option arch
> >
> > gas/config/tc-riscv.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> >
> > base-commit: e472ec9fad6d7b0da914da606430e249d1bd99e4
> > --
> > 2.34.1
> </https:></shihua@iscas.ac.cn></nelson@rivosinc.com></research_trasio@irq.a4lg.com></research_trasio@irq.a4lg.com>
next prev parent reply other threads:[~2022-09-21 10:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-20 9:45 [PATCH V4] RISC-V: Implement Ztso extension shihua
2022-09-21 3:47 ` Nelson Chu
2022-09-21 6:40 ` [PATCH 0/1] RISC-V: Minor fix to the 'Ztso' extension support Tsukasa OI
2022-09-21 6:40 ` [PATCH 1/1] RISC-V: Set EF_RISCV_TSO also on .option arch Tsukasa OI
2022-09-21 7:24 ` Nelson Chu
2022-09-21 9:53 ` [PATCH 0/1] RISC-V: Minor fix to the 'Ztso' extension support shihua
2022-09-21 10:14 ` Tsukasa OI [this message]
2022-09-21 10:21 ` shihua
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aaa59c6a-2729-3bff-50e4-45fbf840752b@irq.a4lg.com \
--to=research_trasio@irq.a4lg.com \
--cc=binutils@sourceware.org \
--cc=nelson@rivosinc.com \
--cc=shihua@iscas.ac.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).