Re: [PATCH, RFC] Add support for choosing disassembler cpu in GDB for POWER.

["Ulrich Weigand" <uweigand@de.ibm.com>]

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
help output.

> 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.

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com