This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 00/10] Make lm_info class hierarchy


On 04/26/2017 11:46 PM, Simon Marchi wrote:
> This patch series makes a class hierarchy out of all the lm_info
> implementations.  This is done to address the problem identified by Pedro in
> [1].

(The other big manifestation of the same problem is with all the
struct gdbarch_tdep types.)

> 
> What I did corresponds to suggestion #1 in Pedro's message.  #3 would probably
> be better, but it's not straightforward.  Some implementations keep their own
> list of lm_info, separate from the global (per pspace) so_list.  So if we
> eliminate the lm_info classes and replace them with classes that extend
> so_list, it's not clear what we should do with these private lists.

For those, we could keep their lm_info as separate objects.  In essence
remove the lm_info pointer from so_list, and move it to the ports
that need it.  I.e., while most ports would do this:

struct bar_solib : so_list
{
  // old lm_info fields here.
};

The ports that want to keep a list of lm_info objects and don't want
that list to be a list of full blown so_list objects could do either:

struct foo_solib : so_list
{
   struct lm_info *lm_info;  // heap allocated.
};

or

struct foo_solib : so_list
{
   struct lm_info lm_info;
};

> So, suggestion #1 is a small step forward, and puts us in good position if we
> want to do #3 one day.  We would then have to change the lm_info_* classes to
> extend so_list instead of lm_info (and probably rename them).

Agreed.  Thanks much for doing this.

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]