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: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: bergner at vnet dot ibm dot com (Peter Bergner)
- Cc: palves at redhat dot com (Pedro Alves), amodra at gmail dot com (Alan Modra), gdb-patches at sourceware dot org, binutils at sourceware dot org (binutils)
- Date: Fri, 28 Oct 2016 16:15:11 +0200 (CEST)
- Subject: Re: [PATCH, RFC] Add support for choosing disassembler cpu in GDB for POWER.
- Authentication-results: sourceware.org; auth=none
Peter Bergner wrote:
> 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?
It's probably not that important to exactly match objdump
behavior here. B.t.w. how do you even enter a space as
separator with the -M option?
> 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?
I thought rather that it would be preferable to refactor the
objdump code first, so that even in objdump, there is already
a generic printing routine that simply works on a list of
option name / description pairs provided by the target back-end.
Then we could simply make that list of option name / description
pairs available to GDB and use it in a GDB generic print routine
that then automatically looks similar to the native objdump
> 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.
If all the existing use cases continue to work, I think this
would be the preferable option.
> > 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.
OK, sounds good.
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain