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

["Aktemur, Tankut Baris" <tankut.baris.aktemur@intel.com>]

On Monday, June 22, 2020 7:00 PM, Simon Marchi wrote:
> On 2020-06-22 12:53 p.m., Aktemur, Tankut Baris via Gdb-patches wrote:
> > On Monday, June 22, 2020 6:40 PM, Simon Marchi wrote:
> >> On 2020-06-22 12:28 p.m., Pedro Alves wrote:
> >>> On 6/21/20 4:32 AM, Simon Marchi wrote:
> >>>>
> >>>> 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).
> >>>
> >>> I'd just like to point out that the main point of the registry mechanism
> >>> is dynamic registration, which is useful when you have parts of the
> >>> debugger that may or not be present in the final build.  E.g.,
> >>> per-stuff data that is only used by some -tdep.c file.  Otherwise,
> >>> if we're talking about data used by some module that is _always_
> >>> included in the built, then IMO the registry stuff is an unnecessary
> >>> abstraction.
> >>
> >> What would you use instead, an explicit field in the objfile structure?
> >>
> >> Simon
> >
> > Can we use an std::unordered_map instead of
> >
> >   static const struct objfile_key<jit_objfile_data> jit_per_objfile;
> >
> > ?
> >
> > -Baris
> 
> An std::unordered_map with the objfile* as the key?  Isn't that pretty much
> what objfile_key does, except that now you must manage it manually (make sure
> the remove the entry when an objfile is deleted)?
> 
> Simon

That's what I meant, but it was because of a confusion with per-architecture data
(e.g. gdbarch_data).  Please ignore.

-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