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.
This commit is contained in:
Simon Marchi 2020-07-22 15:56:07 +02:00 committed by Tankut Baris Aktemur
parent 238b5c9f08
commit 0e74a041c0
4 changed files with 57 additions and 31 deletions

View file

@ -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;
};
/* 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;
/* 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 for this objfile. */
CORE_ADDR addr;
};
/* Looks for the descriptor and registration symbols and breakpoints