public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Anton Kolesov <Anton.Kolesov@synopsys.com>
To: Pedro Alves <palves@redhat.com>, Simon Marchi <simon.marchi@polymtl.ca>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	Francois Bedard	<Francois.Bedard@synopsys.com>
Subject: RE: [PATCH v2] arc: Select CPU model properly before disassembling
Date: Thu, 15 Jun 2017 13:20:00 -0000	[thread overview]
Message-ID: <39A54937CC95F24AA2F794E2D2B66B13587581E1@DE02WEMBXB.internal.synopsys.com> (raw)
In-Reply-To: <02d18307-f315-bc64-d9f3-550feaf01b41@redhat.com>

> 
> I'd think that the "set/show disassembler-options" setting wouldn't ever be
> changed by connecting to a target and that whatever the user explicitly set
> should be respected.
> 
> I.e., gdb / opcodes would choose which cpu to use for disassembly based on
> this logical sequence:
> 
>  - if user specified cpu, use that,
>  - otherwise, if tdesc specified cpu, use that,
>  - otherwise, infer cpu from bfd/elf section,
>  - otherwise, use default cpu

However for ARC we don't support "set disassembler-options", because this
option requires valid disassembler_options to be provided, and arc-tdep.c doesn't
do this - so currently "set disassembler-options ..." reports as unsupported. I
agree that in general this option that comes from XML description probably
should be hidden from the user and not shown via "show disassembler-options".
One possible way is that CPU from target description will be stored in the ARC
gdbarch_tdep, and then will be appended to disassemble_info options in the
arc_delayed_print_insn if cpu= hasn't been specified by the user.  As far as I
can see this situation is pretty specific to ARC, because we have two
bfd_arch_info instances sharing the same machine number (to be compatible with
our proprietary toolchain), so <architecture> tag in XML description doesn't
work the way it should - it selects the first of those two architectures in the
internal BFD list, regardless of which one was actually in the description.

Anton

> 
> Thanks,
> Pedro Alves

  parent reply	other threads:[~2017-06-15 13:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-01 16:02 [PATCH] " Anton Kolesov
2017-06-05 20:07 ` Simon Marchi
2017-06-06 13:51   ` Anton Kolesov
2017-06-13 13:49     ` [PATCH v2] " Anton Kolesov
2017-06-13 22:16       ` Simon Marchi
2017-06-14 14:02         ` Anton Kolesov
2017-06-14 16:27           ` Simon Marchi
2017-06-14 16:37             ` Pedro Alves
2017-06-15 13:20               ` [PATCH v3] " Anton Kolesov
2017-06-15 21:12                 ` Simon Marchi
2017-06-16 12:03                   ` Anton Kolesov
2017-06-15 13:20               ` Anton Kolesov [this message]
2017-06-13 21:31     ` [PATCH] " Simon Marchi

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=39A54937CC95F24AA2F794E2D2B66B13587581E1@DE02WEMBXB.internal.synopsys.com \
    --to=anton.kolesov@synopsys.com \
    --cc=Francois.Bedard@synopsys.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=simon.marchi@polymtl.ca \
    /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).