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 02/10] Make various lm_info implementations inherit from a base class


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


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