public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Peter Bergner <bergner@vnet.ibm.com>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: Pedro Alves <palves@redhat.com>, Alan Modra <amodra@gmail.com>,
	       gdb-patches@sourceware.org,
	binutils <binutils@sourceware.org>
Subject: Re: [PATCH, RFC] Add support for choosing disassembler cpu in GDB for POWER.
Date: Fri, 28 Oct 2016 13:45:00 -0000	[thread overview]
Message-ID: <a774244c-38f8-1b3a-5bc3-38ff694ef516@vnet.ibm.com> (raw)
In-Reply-To: <20161028123236.51A6210B91A@oc8523832656.ibm.com>

On 10/28/16 7:32 AM, Ulrich Weigand wrote:
> really can be handled generically in common code, right?  I.e.
> set_disassembler_options verifies the string is a comma-separated
> list of words from the supported option list, show_disassembler_options
> simply displays the supported option list, etc.

Yes, given Pedro's last comment, that is what I'm working on.
One complication is that some arches (eg, arm) not only allow
comma's as separators, but also allow spaces.  Do we allow
that for all architectures or should an architecture register
which char(s) it allows as separators?

We could add a generic show_disassembler_options loops that dumps
out all of the valid options, but many of the architectures have
functions that already do that, that include extra option info.
I'm hesitant to copy that info over as well as the formatting
will be different since we'll have a common displayer.  I was
thinking of modifying the opcodes/*-dis.c display functions
to take a generic function pointer that they would use to
print their output, then the objdump and gdb calls to that
function could pass fprintf (std.., and fprintf_unfiltered(...
and then things should work and look as before?  Thoughts on that?

My only thought after moving all of this code to generic code is,
how do I handle the arch specific "set <arch> disassenbler..."
code?  One thought is that maybe we don't even need it anymore
and we just always use the generic "set disassembler...." command.
Thoughts?  Otherwise, we'll have to setup the arch specific
routine to call the generic one.


> In fact, once the option processing is done in common code, we don't
> even really need the per-gdbarch disassemble_init_for_target option
> any more, since common code could simply set the disassembler_options
> string before calling disassemble_init_for_target.

I realized that too and have already removed it.  Instead, I'm just
unconditionally setting info->disassembler_options just before calling
disassemble_init_for_target.  For those architectures that don't
opt in for this, it will just set info->disassembler_options to
NULL, which is what it already is doing for them.

Peter



  reply	other threads:[~2016-10-28 13:45 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-30  2:14 Peter Bergner
2016-09-30 17:55 ` Ulrich Weigand
2016-10-03 20:25   ` Peter Bergner
2016-10-03 22:25     ` Alan Modra
2016-10-06  3:00       ` Peter Bergner
2016-10-06  4:44         ` Alan Modra
2016-10-06  9:52         ` Pedro Alves
2016-10-06 19:26           ` Peter Bergner
2016-10-07 19:21             ` Ulrich Weigand
2016-10-07 21:01               ` Peter Bergner
2016-10-08 14:39                 ` Ulrich Weigand
2016-10-10 23:28               ` Peter Bergner
2016-10-12  8:08                 ` Ulrich Weigand
2016-10-12 10:46                   ` Pedro Alves
2016-10-11  0:09             ` Pedro Alves
2016-10-11 18:49               ` Peter Bergner
2016-10-12  8:25                 ` Ulrich Weigand
2016-10-27  0:04                   ` Peter Bergner
2016-10-27  9:40                     ` Pedro Alves
2016-10-28 13:47                       ` Peter Bergner
2016-10-28 14:10                         ` Pedro Alves
2016-10-28 14:24                           ` Peter Bergner
2016-10-28 14:30                             ` Pedro Alves
2016-10-28 14:53                               ` Peter Bergner
2016-11-03 11:01                                 ` Pedro Alves
2016-11-03 15:02                                   ` Peter Bergner
2016-11-03 15:06                                     ` Peter Bergner
2016-11-03 16:41                                     ` Ulrich Weigand
2016-11-03 16:49                                       ` Peter Bergner
2016-10-28 12:32                     ` Ulrich Weigand
2016-10-28 13:45                       ` Peter Bergner [this message]
2016-10-28 14:15                         ` Ulrich Weigand
2016-10-28 15:02                           ` Peter Bergner
2016-10-28 18:47                             ` Ulrich Weigand
2016-11-02 23:28                               ` Peter Bergner
2016-10-12 19:35                 ` Pedro Alves

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=a774244c-38f8-1b3a-5bc3-38ff694ef516@vnet.ibm.com \
    --to=bergner@vnet.ibm.com \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=uweigand@de.ibm.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).