This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH, RFC] Add support for choosing disassembler cpu in GDB for POWER.
- From: Peter Bergner <bergner at vnet dot ibm dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: Pedro Alves <palves at redhat dot com>, Alan Modra <amodra at gmail dot com>, gdb-patches at sourceware dot org, binutils <binutils at sourceware dot org>
- Date: Fri, 28 Oct 2016 08:45:17 -0500
- Subject: Re: [PATCH, RFC] Add support for choosing disassembler cpu in GDB for POWER.
- Authentication-results: sourceware.org; auth=none
- References: <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.