This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v4 1/2] Add back gdb_pretty_print_insn
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