[PATCH v2 3/3] gdb/jit: enable tracking multiple jitter objfiles

[Aktemur, Tankut Baris]

Hi Simon,

On Sunday, June 21, 2020 5:33 AM, Simon Marchi wrote:
> On 2020-06-16 5:49 a.m., Tankut Baris Aktemur wrote:
> >        objf_data = get_jit_objfile_data (reg_symbol.objfile);
> >        objf_data->register_code = reg_symbol.minsym;
> >        objf_data->descriptor = desc_symbol.minsym;
> 
> This made me realize that we now have per-JITer-objfile information in both
> jit_objfile_data and the new jiter_and_bp structure.  I think it would be more
> consistent to bring it all in one of them.
> 
> I see two way forward:
> 
> 1. Move register_code and descriptor from jit_objfile_data to jiter_and_bp.
>    jiter_and_bp becomes the source of truth for information about JITer
>    objfiles.  jit_objfile_data would only be used to decribe JITed objfiles.
> 2. Move the content of jiter_and_bp to jit_objfile_data.
>    If we still think it's useful to have a list of JITer objfiles,
>    jit_program_space_data::jiter_and_bps would become a list of objfiles
>    known to be JITers:
> 
>      /* Objfiles in this program space that define the JIT interface symbols.  */
>      std::forward_list<objfile *> jiters;
> 
> I would prefer #2, because using registries is kind of our standard way to keep
> per-stuff data (where stuff is objfile, program_space, inferior, etc).
> 
> And instead of having the "jiters" list, when we want to iterate on jiters, maybe
> we can just iterate on progspace->objfiles () and check those objfiles whose
> jit_objfile_data indicate they are JITers.  The tradeoff is: it's a bit less
> efficient, but the code is simpler (one less list to maintain, that is possibly
> out of sync).  If the operations that require iterating on the existing JITers are
> not on some hot path, it should be fine.
> 
> While digging into this, there are two improvements I'd make (orthogonal to this
> patch):
> 
> - Make jit.c use the newer / type-safe / c++-friendly objfile_key instead of objfile_data.
> - Split jit_objfile_data in two: one type for the JITers and one type for the JITed.  Even
>   today, it is used for both, and that's kind of confusing.
> 
> I ended up trying all of this to make sure it made sense, instead of just throwing ideas
> out there, so I took the time to make a "clean" branch.  See here:
> 
>   https://github.com/simark/binutils-gdb/tree/multiple-jiters
> 
> Please tell me what you think about this.  If you agree with the direction, I could
> officially post it to the list.

I looked at the patches.  It leads to a much wider cleanup.  Thank you.
This direction makes sense to me.

-Baris


Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Gary Kershaw
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928