public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
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

      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).