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.

0 files changed, 0 insertions, 0 deletions