gdb/jit: split jit_objfile_data in two

The jit_objfile_data is currently used to hold information about both
objfiles that are the result of JIT compilation (JITed) and objfiles
that can produce JITed objfiles (JITers).  I think that this double use
of the type is confusing, and that things would be more obvious if we
had one type for each role.

This patch splits it into:

- jited_objfile_data: for data about an objfile that is the result of a
  JIT compilation
- jiter_objfile_data: for data about an objfile which produces JITed
  objfiles

There are now two JIT-related fields in an objfile, one for each kind.
With this change, the following invariants hold:

- an objfile has a non-null `jiter_data` field iff it defines the required
  symbols of the JIT interface
- an objfile has a non-null `jited_data` field iff it is the product of
  JIT compilation (has been produced by some JITer)

gdb/ChangeLog:
2020-07-22  Simon Marchi  <simon.marchi@polymtl.ca>

	* jit.h (struct jit_objfile_data):  Split into...
	(struct jiter_objfile_data): ... this ...
	(struct jited_objfile_data): ... and this.
	* objfiles.h (struct objfile) <jit_data>: Remove.
	<jiter_data, jited_data>: New fields.
	* jit.c (jit_objfile_data::~jit_objfile_data): Rename to ...
	(jiter_objfile_data::~jiter_objfile_data): ... this.
	(get_jit_objfile_data): Rename to ...
	(get_jiter_objfile_data): ... this.
	(add_objfile_entry): Update.
	(jit_read_descriptor): Use get_jiter_objfile_data.
	(jit_find_objf_with_entry_addr): Use objfile's jited_data field.
	(jit_breakpoint_re_set_internal): Use get_jiter_objfile_data.
	(jit_inferior_exit_hook): Use objfile's jited_data field.

1 files changed, 17 insertions, 11 deletions

diff --git a/gdb/jit.h b/gdb/jit.h
index 6109216..fcef78d 100644
--- a/gdb/jit.h
+++ b/gdb/jit.h
@@ -67,19 +67,16 @@ struct jit_descriptor
   CORE_ADDR first_entry;
 };
 
-/* Per-objfile structure recording the addresses in the program space.
-   This object serves two purposes: for ordinary objfiles, it may
-   cache some symbols related to the JIT interface; and for
-   JIT-created objfiles, it holds some information about the
-   jit_code_entry.  */
+/* An objfile that defines the required symbols of the JIT interface has an
+   instance of this type attached to it.  */
 
-struct jit_objfile_data
+struct jiter_objfile_data
 {
-  jit_objfile_data (struct objfile *objfile)
+  jiter_objfile_data (struct objfile *objfile)
     : objfile (objfile)
   {}
 
-  ~jit_objfile_data ();
+  ~jiter_objfile_data ();
 
   /* Back-link to the objfile. */
   struct objfile *objfile;
@@ -89,10 +86,19 @@ struct jit_objfile_data
 
   /* Symbol for __jit_debug_descriptor.  */
   minimal_symbol *descriptor = nullptr;
+};
+
+/* An objfile that is the product of JIT compilation and was registered
+   using the JIT interface has an instance of this type attached to it.  */
+
+struct jited_objfile_data
+{
+  jited_objfile_data (CORE_ADDR addr)
+    : addr (addr)
+  {}
 
-  /* Address of struct jit_code_entry in this objfile.  This is only
-     non-zero for objfiles that represent code created by the JIT.  */
-  CORE_ADDR addr = 0;
+  /* Address of struct jit_code_entry for this objfile.  */
+  CORE_ADDR addr;
 };
 
 /* Looks for the descriptor and registration symbols and breakpoints