public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Pierre-Marie de Rodat <derodat@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] [Ada] Enhance type printing for arrays with variable-sized elements
Date: Tue, 15 Sep 2015 16:06:00 -0000	[thread overview]
Message-ID: <20150915160611.GA20575@adacore.com> (raw)
In-Reply-To: <1442315486-4885-1-git-send-email-derodat@adacore.com>

> Before this change, we would get the following GDB session:
> 
>     (gdb) ptype a
>     type = array (1 .. 2) of foo.r_type <packed: 838-bit elements>
> 
> This is wrong: "a" is not a packed array.  This output comes from the
> fact that, because R_Type has a dynamic size (with a maximum), the
> compiler has to describe in the debugging information the size allocated
> for each array element (i.e. the stride, in DWARF parlance: see
> DW_AT_byte_stride).  Ada type printing currently assumes that arrays
> with a stride are packed, hence the above output.
> 
> In practice, GNAT never performs bit-packing for arrays that contain
> variable-sized elements.  Leveraging this fact, this patch enhances type
> printing so that ptype does not pretend that arrays are packed when they
> have a stride and they contain dynamic elements.  After this change, we
> get the following expected output:
> 
>     (gdb) ptype a
>     type = array (1 .. 2) of foo.r_type
> 
> gdb/ChangeLog:
> 
> 	* ada-typeprint.c (print_array_type): Do not describe arrays as
> 	packed when they embed dynamic elements.
> 
> gdb/testsuite/ChangeLog:
> 
> 	* gdb.ada/array_of_variable_length.exp: New testcase.
> 	* gdb.ada/array_of_variable_length/foo.adb: New file.
> 	* gdb.ada/array_of_variable_length/pck.adb: New file.
> 	* gdb.ada/array_of_variable_length/pck.ads: New file.

This looks like an easy improvement. Thanks, Pierre-Marie!

I'm curious - what happens if you do:

    (gdb) print a
    (gdb) ptype $

The concern is that $ refers to the resolved version of "A", and
that therefore we might lose the dynamic property. But I think it will
work in this case, because we do not resolve the array's element type
(each element of the actual array has to be resolved individually,
since the actual type changes from element to element).

It's worth extending your new testcase with the above scenario as well,
I think.

Other than that, the patch itself looks pretty good to me.

-- 
Joel

  reply	other threads:[~2015-09-15 16:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-15 11:11 Pierre-Marie de Rodat
2015-09-15 16:06 ` Joel Brobecker [this message]
2015-09-15 21:19   ` Pierre-Marie de Rodat

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=20150915160611.GA20575@adacore.com \
    --to=brobecker@adacore.com \
    --cc=derodat@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).