aboutsummaryrefslogtreecommitdiff
path: root/gdb/mips-tdep.c
diff options
context:
space:
mode:
authorAndrew Burgess <andrew.burgess@embecosm.com>2021-10-27 10:07:56 +0100
committerAndrew Burgess <aburgess@redhat.com>2022-06-15 09:44:54 +0100
commitf0c2e3e020d350b410e1bbe4ed636f2ea228d555 (patch)
treee27ca17e48a702c63330b2c6e4852d7a594284d8 /gdb/mips-tdep.c
parent8a0b60471a75ce81b8ea067f6e87457b3ed0c7a3 (diff)
downloadgdb-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.c4
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