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