This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 02/10] Make various lm_info implementations inherit from a base class
- From: Pedro Alves <palves at redhat dot com>
- To: Simon Marchi <simon dot marchi at ericsson dot com>, gdb-patches at sourceware dot org
- Cc: Simon Marchi <simon dot marchi at polymtl dot ca>
- Date: Fri, 28 Apr 2017 16:57:53 +0100
- Subject: Re: [PATCH 02/10] Make various lm_info implementations inherit from a base class
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx09.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 AE6FE248501
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com AE6FE248501
- References: <20170426224706.27988-1-simon.marchi@ericsson.com> <20170426224706.27988-3-simon.marchi@ericsson.com>
On 04/26/2017 11:46 PM, Simon Marchi wrote:
> From: Simon Marchi <simon.marchi@polymtl.ca>
>
> The lm_info structure is used to store target specific information about
> mapped libraries. It is currently defined as an opaque type in solist.h
> and a pointer to it is included in solist, the target-agnostic object
> representing a loaded shared library. Multiple targets define their own
> implementation of lm_info.
>
> In anticipation of using C++ stuff (e.g. vector) in the lm_info objects,
> we first need to avoid different definitions of classes with the same
> name (which violates the one definition rule). This patch does it by
> having a base class (lm_info_base) from which all the specific lm_info
> derive. Each implementation is renamed to something that makes sense
> (e.g. lm_info_aix for AIX). The next logical step would probably be to
> derive directly from so_list, but it's not really obvious, so I'll keep
> that for another day.
>
> One special case is the Neutrino (nto) support. It uses SVR4-style
> libraries, but overrides some methods. To do that, it needed to have
> its own copy of SVR4's lm_info structure in nto-tdep.c, because it was
> just not possible to put it in solib-svr4.h and include that file. Over
> time, that copy got out of sync, which is still the case today. I can
> only assume that the lm_addr function in nto-tdep.c is broken right now.
> The first field of the old lm_info was a pointer (gdb_byte *), whereas
> in the new lm_info it's an address in the inferior (CORE_ADDR). Trying
> to use that field today probably results in a crash. With this
> refactor, it's now possible to put lm_info_svr4 in solib-svr4.h and just
> include it. I have adapted the code in nto-tdep.c to that it builds,
> but it's probably not correct. Since I don't have the knowledge nor
> setup to try this on Neutrino, somebody else would have to fix it. But
> I am confident that I am not making things worse than they already are.
LGTM.
Thanks,
Pedro Alves