This is the mail archive of the
mailing list for the GDB project.
Re: [Patch v2 01/10] vla: introduce new bound type abstraction adapt uses
- From: Doug Evans <xdje42 at gmail dot com>
- To: Sanimir Agovic <sanimir dot agovic at intel dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, gdb-patches at sourceware dot org, keven dot boell at intel dot com
- Date: Sat, 23 Nov 2013 11:27:05 -0800
- Subject: Re: [Patch v2 01/10] vla: introduce new bound type abstraction adapt uses
- Authentication-results: sourceware.org; auth=none
- References: <1385044223-24650-1-git-send-email-sanimir dot agovic at intel dot com> <1385044223-24650-2-git-send-email-sanimir dot agovic at intel dot com>
On Thu, Nov 21, 2013 at 6:30 AM, Sanimir Agovic
> The rational behind this patch is to get started to implement the feature
> described in dwarf4 standard (2.19) Static and Dynamic Values of Attributes.
> It adds new DWARF2_PROP to store either a constant, exprloc, or reference to
> describe an upper-/lower bound of a subrange. Other than that no new features
> are introduce.
> 2013-10-18 Sanimir Agovic <email@example.com>
> Keven Boell <firstname.lastname@example.org>
> * dwarf2read.c (read_subrange_type): Use struct dwarf2_prop for
> declaring high/low bounds and change uses accordingly. Call
> create_range_type_1 instead of create_range_type,
> * gdbtypes.c (create_range_type_1): New function.
> (create_range_type): Convert bounds into struct dwarf2_prop and pass
> them to create_range_type_1.
> * gdbtypes.h (struct dwarf2_prop): New struct.
> (create_range_type_1): New function prototype.
> (struct range_bounds): Use struct dwarf2_prop instead of LONGEST for
> high/low bounds. Remove low_undefined/high_undefined and adapt all uses.
> (TYPE_LOW_BOUND,TYPE_HIGH_BOUND): Adapt macros to refer to the static
> part of the bound.
> * parse.c (follow_types): Set high bound kind to DWARF_UNDEFINED.
Do we know other debug formats don't support dynamic ranges?
There are various abstraction boundaries that gdb tries to maintain
between gdb proper and other pieces (like debug format readers).
We don't always maintain these boundaries (e.g., grep for existing
uses of the word "dwarf" in gdbtypes.h) but IWBN to at least have a
discussion every time such boundaries are violated.
The trivial way to fix this in cases such as these, is of course to,
basically, not use the word "dwarf" in anything that is used in gdb
proper (modulo the the very few cases where we call into dwarf*.c).
Whether it's sufficient and/or worth it in any particular situation is
of course *the* question. But it doesn't feel right to proceed
without having it being asked and answered.