From: "Maciej W. Rozycki" <macro@wdc.com>
To: gdb-patches@sourceware.org
Cc: Jim Wilson <jimw@sifive.com>,
Andrew Burgess <andrew.burgess@embecosm.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Tom Tromey <tom@tromey.com>,
guoren@kernel.org, lifang_xia@c-sky.com,
yunhai_shang@c-sky.com, jiangshuai_li@c-sky.com
Subject: [PATCH v3 0/3] RISC-V/Linux `gdbserver' support and associated fixes
Date: Fri, 31 Jan 2020 12:12:00 -0000 [thread overview]
Message-ID: <alpine.LFD.2.21.2001311115550.14118@redsun52.ssa.fujisawa.hgst.com> (raw)
Hi,
This is v3 of my RISC-V/Linux `gdbserver' support proposal.
Beyond the issues discussed with v2 I have now also slightly optimised
regcache supply/collect handlers to avoid doing a costly variable
multiplication in a loop, and added buffer offset precalculations so as to
avoid excessive line wrapping and hopefully making code more readable.
Also I have noticed missing Python and ncurses development libraries
limiting testing in my native setup. With these installed native test
results improved a little, as follows:
=== gdb Summary ===
# of expected passes 61354
# of unexpected failures 1636
# of unexpected successes 1
# of expected failures 58
# of unknown successes 3
# of known failures 85
# of unresolved testcases 113
# of untested testcases 160
# of unsupported tests 323
however a worrying regression has appeared:
FAIL: gdb.base/return-nodebug.exp: float: full width of the returned result
This has turned out not to be related to this patch series however and
triggers reliably now in my setup regardless of whether this patch set has
been applied or not. Instead it is an outcome of GDB failing to NaN-box
data of the `float' type when assigning it to a hardware register.
I have filed PR tdep/25489 to track it as I may not be able to look into
it right away.
Except as noted above here have been no regressions in native
`riscv64-linux-gnu' testing and remote `gdbserver' test results are the
same as previously (barring the usual gdb.threads/ fluctuations).
As usually see individual changes for details.
Maciej
next reply other threads:[~2020-01-31 12:11 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-31 12:12 Maciej W. Rozycki [this message]
2020-01-31 13:00 ` Maciej W. Rozycki
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=alpine.LFD.2.21.2001311115550.14118@redsun52.ssa.fujisawa.hgst.com \
--to=macro@wdc.com \
--cc=andrew.burgess@embecosm.com \
--cc=gdb-patches@sourceware.org \
--cc=guoren@kernel.org \
--cc=jiangshuai_li@c-sky.com \
--cc=jimw@sifive.com \
--cc=lifang_xia@c-sky.com \
--cc=palmer@dabbelt.com \
--cc=tom@tromey.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