diff options
author | Andrew Burgess <andrew.burgess@embecosm.com> | 2021-10-27 10:07:56 +0100 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2022-06-15 09:44:54 +0100 |
commit | f0c2e3e020d350b410e1bbe4ed636f2ea228d555 (patch) | |
tree | e27ca17e48a702c63330b2c6e4852d7a594284d8 /gdb/mips-tdep.c | |
parent | 8a0b60471a75ce81b8ea067f6e87457b3ed0c7a3 (diff) | |
download | gdb-f0c2e3e020d350b410e1bbe4ed636f2ea228d555.zip gdb-f0c2e3e020d350b410e1bbe4ed636f2ea228d555.tar.gz gdb-f0c2e3e020d350b410e1bbe4ed636f2ea228d555.tar.bz2 |
gdb: add new base class to gdb_disassembler
The motivation for this change is an upcoming Python disassembler API
that I would like to add. As part of that change I need to create a
new disassembler like class that contains a disassemble_info and a
gdbarch. The management of these two objects is identical to how we
manage these objects within gdb_disassembler, so it might be tempting
for my new class to inherit from gdb_disassembler.
The problem however, is that gdb_disassembler has a tight connection
between its constructor, and its print_insn method. In the
constructor the ui_file* that is passed in is replaced with a member
variable string_file*, and then in print_insn, the contents of the
member variable string_file are printed to the original ui_file*.
What this means is that the gdb_disassembler class has a tight
coupling between its constructor and print_insn; the class just isn't
intended to be used in a situation where print_insn is not going to be
called, which is how my (upcoming) sub-class would need to operate.
My solution then, is to separate out the management of the
disassemble_info and gdbarch into a new gdb_disassemble_info class,
and make this class a parent of gdb_disassembler.
In arm-tdep.c and mips-tdep.c, where we used to cast the
disassemble_info->application_data to a gdb_disassembler, we can now
cast to a gdb_disassemble_info as we only need to access the gdbarch
information.
Now, my new Python disassembler sub-class will still want to print
things to an output stream, and so we will want access to the
dis_asm_fprintf functionality for printing.
However, rather than move this printing code into the
gdb_disassemble_info base class, I have added yet another level of
hierarchy, a gdb_printing_disassembler, thus the class structure is
now:
struct gdb_disassemble_info {};
struct gdb_printing_disassembler : public gdb_disassemble_info {};
struct gdb_disassembler : public gdb_printing_disassembler {};
In a later commit my new Python disassembler will inherit from
gdb_printing_disassembler.
The reason for adding the additional layer to the class hierarchy is
that in yet another commit I intend to rewrite the function
gdb_buffered_insn_length, and to do this I will be creating yet more
disassembler like classes, however, these will not print anything,
thus I will add a gdb_non_printing_disassembler class that also
inherits from gdb_disassemble_info. Knowing that that change is
coming, I've gone with the above class hierarchy now.
There should be no user visible changes after this commit.
Diffstat (limited to 'gdb/mips-tdep.c')
-rw-r--r-- | gdb/mips-tdep.c | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/gdb/mips-tdep.c b/gdb/mips-tdep.c index 805c5be..65aa86d 100644 --- a/gdb/mips-tdep.c +++ b/gdb/mips-tdep.c @@ -7021,8 +7021,8 @@ reinit_frame_cache_sfunc (const char *args, int from_tty, static int gdb_print_insn_mips (bfd_vma memaddr, struct disassemble_info *info) { - gdb_disassembler *di - = static_cast<gdb_disassembler *>(info->application_data); + gdb_disassemble_info *di + = static_cast<gdb_disassemble_info *> (info->application_data); struct gdbarch *gdbarch = di->arch (); /* FIXME: cagney/2003-06-26: Is this even necessary? The |