Re: [PATCH v4 1/2] Add back gdb_pretty_print_insn

[Pedro Alves <palves@redhat.com>]

On 02/01/2017 08:01 PM, Pedro Alves wrote:

> Yeah.  It's simple to add a string_file parameter to gdb_pretty_print_insn,
> in order to pass in a buffer that is reused, like it used to be,
> if found necessary.
> 
> gdb_disassembler is on the stack so practically doesn't
> count, in overhead terms.  I think for this series it may end
> up balanced by allocating fewer cleanups, and also I suspect
> most disassembled instructions fit std::string's
> "small string optimization", meaning no heap allocation.

If we do that, I think a better idea occurred to me.  Note that
gdb_disassembler::pretty_print_insn has yet another local
buffer:

      /* Build the opcodes using a temporary stream so we can
	 write them out in a single go for the MI.  */
      struct ui_file *opcode_stream = mem_fileopen ();
      struct cleanup *cleanups =
	make_cleanup_ui_file_delete (opcode_stream);

so it would make sense to treat both buffers the same
way.  I.e., if we want to reuse one, we should probably
reuse both.  Which suggests creating a new struct to hold
whatever should survive across calls.  And then we can
go the step further, and make that a class, with
pretty_print_insn a method of _that_ class instead of
of gdb_disassembler.  Like:

struct gdb_pretty_disassembler
{
  int pretty_print_insn (struct ui_out *uiout, 
                         const struct disasm_insn *insn,
                         int flags);

private:
  string_file m_insn_buffer;
  string_file m_opcode_buffer;
};

and then the use in loops would be something like:

func ()
{
  gdb_pretty_disassembler disasm;

  while (whatever)
    {
       disasm.print_insn (uiout, ....);
    }
}

I can try that, but I think I'd rather do it after
string_file is in already.

Thanks,
Pedro Alves