From: "Palmer Dabbelt via binutils" <binutils@sourceware.org>
To: Jim Wilson <jimw@sifive.com>, macro@wdc.com
Cc: Jim Wilson <jimw@sifive.com>, binutils@sourceware.org
Subject: Re: [PATCH] RISC-V: Fix gdbserver problem with handling arch strings.
Date: Thu, 30 Jan 2020 15:41:00 -0000 [thread overview]
Message-ID: <mhng-e793544f-0ca4-4dfe-bcda-6dd606dec397@palmerdabbelt-glaptop1> (raw)
In-Reply-To: <alpine.LFD.2.21.2001241321370.14118@redsun52.ssa.fujisawa.hgst.com>
On Fri, 24 Jan 2020 13:32:13 GMT (+0000), macro@wdc.com wrote:
> On Thu, 23 Jan 2020, Jim Wilson wrote:
>
>> Maciej reported a problem found by his RISC-V gdbserver port.
>> warning: while parsing target description (at line 4): Target description specified unknown architecture "riscv:rv64id"
>> warning: Could not load XML target description; ignoring
>>
>> We only have two arches defined, riscv:rv32 and riscv:rv64. Both bfd and
>> gdb are creating arch strings that have extension letters added to the base
>> architecture. The bfd_default_scan function requires an exact match, so
>> these strings fail to map to a bfd_arch. I think we should ignore the
>> extension letters in a RISC-V specific scan function.
>
> I think it's an acceptable solution short-term; after all it's not going
> to regress functionality. However ultimately I think we ought to actually
> interpret these suffix letters and arm the disassembler accordingly.
>
>> Tested with riscv{32,64}-{elf,linux} cross build and test with no regressions.
>
> I'll push it through GDB testing with `gdbserver' yet, once my current
> native testing has completed (which BTW will take till the end of today
> only as it seems to run ~4 times faster now; presumably some test cases do
> not time out anymore).
>
>> Not committed yet in case anyone wanted to comment on it before I check it in.
>
> I'd suggest naming the new function `riscv_scan' or suchlike, even though
> it's static, so as not to pollute the generic namespace. We even have a
> precedent already with `riscv_compatible' nearby.
>
> Thanks for the quick fix!
Yep, feel free to commit it -- I still don't have my SSH key set up over here
yet...
Thanks!
>
> Maciej
prev parent reply other threads:[~2020-01-30 15:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-24 2:09 Jim Wilson
2020-01-24 13:32 ` Maciej W. Rozycki
2020-01-24 22:38 ` Jim Wilson
2020-01-27 13:04 ` Maciej W. Rozycki
2020-01-27 20:31 ` Jim Wilson
2020-01-27 23:24 ` [PATCH v2] " Jim Wilson
2020-01-30 15:41 ` Palmer Dabbelt via binutils [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=mhng-e793544f-0ca4-4dfe-bcda-6dd606dec397@palmerdabbelt-glaptop1 \
--to=binutils@sourceware.org \
--cc=jimw@sifive.com \
--cc=macro@wdc.com \
--cc=palmerdabbelt@google.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).