From: Jim Wilson <jimw@sifive.com>
To: Guo Ren <guoren@kernel.org>
Cc: jiangshuai_li@c-sky.com, "Maciej Rozycki" <macro@wdc.com>,
"Andrew Burgess" <andrew.burgess@embecosm.com>,
gdb-patches@sourceware.org, 夏立方 <lifang_xia@c-sky.com>,
yunhai_shang <yunhai_shang@c-sky.com>
Subject: Re: [PATCH] riscv: add gdbserver support
Date: Wed, 22 Jan 2020 06:15:00 -0000 [thread overview]
Message-ID: <CAFyWVaZGAS7yw1O1gZ4yEBY06LVegcKoja7z_p8WewsP5Qbiog@mail.gmail.com> (raw)
In-Reply-To: <CAJF2gTSQDb=qZO91x8J7y3gMyJtDLWyKBYKUTd5oX0qars9W+w@mail.gmail.com>
On Tue, Jan 21, 2020 at 6:15 PM Guo Ren <guoren@kernel.org> wrote:
> In fact, both T-HEAD XuanTie C910 and Andes 27-series CPU cores claim
> to support vector extensions, which is good for riscv-v extenstion.
I believe the XuanTie C910 part implemented the 0.7.1 draft, I have no
idea what Andes implemented. SiFive also has vector support in
development. But my concern here is that we have different chips
implementing different incompatible draft versions of the vector spec.
This is going to be a nightmare to maintain. These draft versions of
the vector spec never should have been implemented in released
hardware.
> Many complex linux vector development/test-suite need linux/gdb/glibc
> to support the vector-regs' context.
The binutils support is on a branch in a github.com/riscv repo,
waiting for the vector extension to reach its final form. We are only
planning to upstream support for the official vector extension, not
any of the conflicting draft proposals. The same could be done for
other parts of the vector support. We can create branches in the
riscv repos, or we could create branches in upstream repos. We don't
have to add patches now that may conflict with the official vector
extension support.
As for gdb, it is still the case that no one has made a psabi proposal
to assign dwarf register numbers to the vector registers.
Jim
prev parent reply other threads:[~2020-01-22 6:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-15 5:01 jiangshuai_li
2020-01-20 23:33 ` Jim Wilson
2020-01-21 0:30 ` Maciej W. Rozycki
2020-01-21 2:13 ` Simon Marchi
2020-01-21 2:17 ` Maciej W. Rozycki
2020-01-21 13:01 ` Andrew Burgess
2020-01-21 13:28 ` Andrew Burgess
2020-01-21 13:47 ` Andreas Schwab
2020-01-22 0:11 ` Jim Wilson
2020-01-22 0:45 ` Jim Wilson
2020-01-22 10:19 ` Jim Wilson
2020-01-22 14:08 ` Andrew Burgess
2020-01-21 23:56 ` Jim Wilson
2020-01-22 5:26 ` Guo Ren
2020-01-22 6:15 ` Jim Wilson [this message]
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=CAFyWVaZGAS7yw1O1gZ4yEBY06LVegcKoja7z_p8WewsP5Qbiog@mail.gmail.com \
--to=jimw@sifive.com \
--cc=andrew.burgess@embecosm.com \
--cc=gdb-patches@sourceware.org \
--cc=guoren@kernel.org \
--cc=jiangshuai_li@c-sky.com \
--cc=lifang_xia@c-sky.com \
--cc=macro@wdc.com \
--cc=yunhai_shang@c-sky.com \
/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