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

[Simon Marchi <simark@simark.ca>]

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