This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Peter Bergner wrote:
> On 10/10/16 7:08 PM, Pedro Alves wrote:
> > A command that works for all architectures, like your original
> > "set disassembler-cpu" seemingly would be (ignoring implementation
> > details).  Maybe "set disassembler-cpu" could be an alias for
> > "set $current_arch disassembler-cpu".  GDB would then only need to store
> > a disassemble option string for each possible arch, and the alias would just
> > need to map the current arch's cpu to the right option string variable.
> It doesn't look like set_disassembler_cpu() is passed the gdbarch, so
> is there some global variable that it could use to determine what the
> current arch is?  That said, even if I do have it, wouldn't we need
> to store the set/show commands in the gdbarch so that they can be
> called?

A platform-independent set_disassemble_options() (or whatever it is
called) command should probably reside in disasm.c, and be installed
via (a newly added) _initialize_disasm initializer routine there.

To get at the current gdbarch, you can use get_current_arch ().  This
function should be rarely used, but the one place where it *is* fine
is exactly in top-level command implementation routines.

> > All the information to build this should be in opcodes, I think.  Even
> > for "help show disassembler-cpu", it should be possible for gdb to ask
> > opcodes to print a description of each possible option,
> > since "objdump --help" does it.  Bonus points for hooking that to
> > a completer for "set disassembler-cpu <tab>".  :-)
> The objdump --help output comes from opcodes/ppc-dis.c's
> print_ppc_disassembler_options(FILE *stream).  I actually tried
> to call that from show_disassembler_cpu(), but the "file" pointer
> it's passed is of type "struct ui_file *file" which looks to be
> a black box, so I'm not sure how I can extract a "FILE *" pointer
> out of that.

That doesn't work in general; some "ui_file"s are based on FILE *,
but not all of them.  One way would be to create a memory-buffer
based FILE * via fmemopen or open_memstream and pass that to the
opcodes routine.  However, those routines are probably not available
on all systems supported by GDB ...

Another option might be to refactor the way disassembler options
output is done in opcodes, e.g. by having platform-specific code
only provide an array of tuples of option names and explanatory
strings, and move the actual printing to common code.  Then those
arrays could be exported to and reused by GDB.  (In particular,
there's really no way to do a completer without such information.)

> I don't know how to set up a completer and I don't see one.
> Do you know of an example in the code I could look at/copy?

You need to implement a completer callback and install it for
your command via set_cmd_completer.  There's a couple of examples
to look at, but for something like this where there is a predefined
list of available options, you should probably simply use the
complete_on_enum helper in your completer, like e.g. done in


  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]