From: Ken Werner <ken@linux.vnet.ibm.com>
To: gdb-patches@sourceware.org
Cc: Tom Tromey <tromey@redhat.com>
Subject: Re: [patch] DW_AT_byte_size for array type entries
Date: Mon, 13 Dec 2010 20:03:00 -0000 [thread overview]
Message-ID: <201012132103.09320.ken@linux.vnet.ibm.com> (raw)
In-Reply-To: <201011031522.50715.ken@linux.vnet.ibm.com>
[-- Attachment #1: Type: Text/Plain, Size: 1999 bytes --]
On Wednesday, November 03, 2010 3:22:50 pm Ken Werner wrote:
> On Tuesday, November 02, 2010 11:31:03 pm Tom Tromey wrote:
> > >>>>> "Ken" == Ken Werner <ken@linux.vnet.ibm.com> writes:
> > Ken> Index: gdb/c-valprint.c
> > Ken> ===================================================================
> > Ken> RCS file: /cvs/src/src/gdb/c-valprint.c,v
> > Ken> retrieving revision 1.74
> > Ken> diff -p -u -r1.74 c-valprint.c
> > Ken> --- gdb/c-valprint.c 15 Oct 2010 18:54:12 -0000 1.74
> > Ken> +++ gdb/c-valprint.c 19 Oct 2010 12:15:30 -0000
> > Ken> @@ -171,8 +171,13 @@ c_val_print (struct type *type, const gd
> > Ken> elttype = check_typedef (unresolved_elttype);
> > Ken> if (TYPE_LENGTH (type) > 0 && TYPE_LENGTH
> > (unresolved_elttype)
> >
> > > 0) Ken> {
> >
> > Ken> + LONGEST low_bound, high_bound;
> > Ken> +
> > Ken> + if (!get_array_bounds(type, &low_bound, &high_bound))
> >
> > Missing space before open paren.
>
> Fixed.
>
> > Ken> + error (_("Could not determine the array high bound"));
> > Ken> +
> > Ken> eltlen = TYPE_LENGTH (elttype);
> > Ken> - len = TYPE_LENGTH (type) / eltlen;
> > Ken> + len = high_bound - low_bound + 1;
> >
> > I guess it is ok to use 'eltlen' elsewhere in the function because it is
> > only the array's overall size which is "weird" -- the element size is
> > still correct. (Since we don't implement the DWARF stride stuff...)
>
> Yes, that is also my understanding.
>
> > The patch is ok with the above nit fixed.
>
> Thanks. I've checked in the version below:
> http://sourceware.org/ml/gdb-cvs/2010-11/msg00014.html
Hi,
The attached patch changes the value_one(), value_complement() and value_neg()
functions to use get_array_bounds to compute the number of array elements
instead of dividing the length of the array by the length of the element
types. It seems that I overlooked these in the first place.
Tested on i686-*-linux-gnu with no regressions.
Ok to apply?
Regards
Ken
[-- Attachment #2: arraybounds.patch --]
[-- Type: text/x-patch, Size: 2724 bytes --]
2010-12-13 Ken Werner <ken.werner@de.ibm.com>
* valops.c (value_one): Use get_array_bounds to compute the number
of array elements instead of dividing the length of the array by the
length of the element types.
* valarith.c (value_complement, value_neg): Likewise.
Index: gdb/valarith.c
===================================================================
RCS file: /cvs/src/src/gdb/valarith.c,v
retrieving revision 1.91
diff -u -r1.91 valarith.c
--- gdb/valarith.c 29 Nov 2010 21:18:16 -0000 1.91
+++ gdb/valarith.c 13 Dec 2010 19:43:52 -0000
@@ -1766,9 +1766,13 @@
{
struct value *tmp, *val = allocate_value (type);
struct type *eltype = check_typedef (TYPE_TARGET_TYPE (type));
- int i, n = TYPE_LENGTH (type) / TYPE_LENGTH (eltype);
+ int i;
+ LONGEST low_bound, high_bound;
- for (i = 0; i < n; i++)
+ if (!get_array_bounds (type, &low_bound, &high_bound))
+ error (_("Could not determine the vector bounds"));
+
+ for (i = 0; i < high_bound - low_bound + 1; i++)
{
tmp = value_neg (value_subscript (arg1, i));
memcpy (value_contents_writeable (val) + i * TYPE_LENGTH (eltype),
@@ -1798,10 +1802,14 @@
{
struct value *tmp;
struct type *eltype = check_typedef (TYPE_TARGET_TYPE (type));
- int i, n = TYPE_LENGTH (type) / TYPE_LENGTH (eltype);
+ int i;
+ LONGEST low_bound, high_bound;
+
+ if (!get_array_bounds (type, &low_bound, &high_bound))
+ error (_("Could not determine the vector bounds"));
val = allocate_value (type);
- for (i = 0; i < n; i++)
+ for (i = 0; i < high_bound - low_bound + 1; i++)
{
tmp = value_complement (value_subscript (arg1, i));
memcpy (value_contents_writeable (val) + i * TYPE_LENGTH (eltype),
Index: gdb/valops.c
===================================================================
RCS file: /cvs/src/src/gdb/valops.c,v
retrieving revision 1.259
diff -u -r1.259 valops.c
--- gdb/valops.c 1 Dec 2010 16:49:41 -0000 1.259
+++ gdb/valops.c 13 Dec 2010 19:43:52 -0000
@@ -877,11 +877,15 @@
else if (TYPE_CODE (type1) == TYPE_CODE_ARRAY && TYPE_VECTOR (type1))
{
struct type *eltype = check_typedef (TYPE_TARGET_TYPE (type1));
- int i, n = TYPE_LENGTH (type1) / TYPE_LENGTH (eltype);
+ int i;
+ LONGEST low_bound, high_bound;
struct value *tmp;
+ if (!get_array_bounds (type1, &low_bound, &high_bound))
+ error (_("Could not determine the vector bounds"));
+
val = allocate_value (type);
- for (i = 0; i < n; i++)
+ for (i = 0; i < high_bound - low_bound + 1; i++)
{
tmp = value_one (eltype, lv);
memcpy (value_contents_writeable (val) + i * TYPE_LENGTH (eltype),
next prev parent reply other threads:[~2010-12-13 20:03 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-19 11:24 Ken Werner
2010-10-19 18:16 ` Ken Werner
2010-11-02 8:23 ` Ken Werner
2010-11-02 22:45 ` Tom Tromey
2010-11-03 14:23 ` Ken Werner
2010-11-03 19:09 ` Regression on gdb.ada/null_array.exp [Re: [patch] DW_AT_byte_size for array type entries] Jan Kratochvil
2010-11-03 21:16 ` Joel Brobecker
2010-11-03 23:22 ` [commit/Ada] fix warning when printing empty array Joel Brobecker
2010-11-03 23:24 ` Regression on gdb.ada/null_array.exp [Re: [patch] DW_AT_byte_size for array type entries] Joel Brobecker
2010-11-04 0:31 ` Jan Kratochvil
2010-11-04 1:57 ` Joel Brobecker
2010-11-04 3:26 ` Jan Kratochvil
2010-11-04 18:01 ` Joel Brobecker
2010-11-04 18:10 ` Jan Kratochvil
2010-11-04 18:23 ` Joel Brobecker
2010-11-04 18:54 ` Jan Kratochvil
2010-11-04 22:11 ` Joel Brobecker
2010-12-13 20:03 ` Ken Werner [this message]
2010-12-14 5:42 ` [patch] DW_AT_byte_size for array type entries Joel Brobecker
2010-12-14 10:27 ` Ken Werner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201012132103.09320.ken@linux.vnet.ibm.com \
--to=ken@linux.vnet.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox