This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 00/10] Make lm_info class hierarchy
- From: Pedro Alves <palves at redhat dot com>
- To: Simon Marchi <simon dot marchi at ericsson dot com>, gdb-patches at sourceware dot org
- Date: Fri, 28 Apr 2017 17:08:38 +0100
- Subject: Re: [PATCH 00/10] Make lm_info class hierarchy
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=palves at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com E5D287EAB8
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E5D287EAB8
- References: <20170426224706.27988-1-simon.marchi@ericsson.com>
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