This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [V4 01/18] vla: introduce allocated/associated flags
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Keven Boell <keven dot boell at intel dot com>
- Cc: gdb-patches at sourceware dot org, Doug Evans <dje at google dot com>
- Date: Mon, 9 Feb 2015 10:52:13 +0400
- Subject: Re: [V4 01/18] vla: introduce allocated/associated flags
- Authentication-results: sourceware.org; auth=none
- References: <1421243390-24015-1-git-send-email-keven dot boell at intel dot com> <1421243390-24015-2-git-send-email-keven dot boell at intel dot com>
[Copying Doug, as I think Doug has experience in this area, and is
also dealing with the kind of giant programs where size of types
really make a big difference]
> Fortran 90 provide types whose values may be dynamically
> allocated or associated with a variable under explicit
> program control. The purpose of this commit is to read
> allocated/associated DWARF tags and store them to the
> main_type.
>
> 2014-05-28 Keven Boell <keven.boell@intel.com>
> Sanimir Agovic <sanimir.agovic@intel.com>
>
> * dwarf2read.c (set_die_type): Add reading of
> allocated/associated flags.
> * gdbtypes.h (struct main_type): Add allocated/
> associated dwarf2_prop attributes.
> (TYPE_ALLOCATED_PROP): New macro.
> (TYPE_ASSOCIATED_PROP): New macro.
> (TYPE_NOT_ALLOCATED): New macro.
> (TYPE_NOT_ASSOCIATED): New macro.
struct main_type is size-critical, so we simply cannot add
fields to it that only a very small minority of instances
will actually be using..
To avoid the size increase, I propose that we turn...
struct dynamic_prop *data_location;
... into a chained list of dynamic properties. To determine
which type of property each element in the list is, we'll need
to introduce an enumerated type to be used as discriminant.
So, I propose something like that:
/* FIXME: Add comment. */
enum dynamic_prop_kind
{
/* FIXME: Document. */
DYNAMIC_PROP_DATA_LOCATION,
/* FIXME: Document. */
DYNAMIC_PROP_ALLOCATED,
/* FIXME: Document. */
DYNAMIC_PROP_ASSOCIATED,
};
/* FIXME: Document. */
struct dynamic_prop_list
{
enum dynamic_prop_kind kind;
struct dynamic_prop *prop;
struct dynamic_prop_list *next;
};
... then replace...
struct dynamic_prop *data_location;
... into ...
struct dynamic_prop_list *dyn_prop_list;
... and finally adjust the macros to go through the list instead of
accessing the data through the dedicated fields. Using a function
which does the search for a given kind will probably be useful.
I think you might find it easier to do it in 2 stages (and therefore
two patches):
1. Convert the current "data_location" field to the list scheme;
2. Then add the two new kinds of properties, which should then
be fairly straightforward.
--
Joel