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:
parent
238b5c9f08
commit
0e74a041c0
4 changed files with 57 additions and 31 deletions
28
gdb/jit.h
28
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;
|
||||
};
|
||||
|
||||
/* 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
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue