From: Gaius Mulley <gaius@glam.ac.uk>
To: Jim Blandy <jimb@codesourcery.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
deuling@de.ibm.com, gdb-patches@sources.redhat.com
Subject: Re: [PATCH] Unbounded array support implemented (for Modula-2)
Date: Tue, 31 Jul 2007 16:47:00 -0000 [thread overview]
Message-ID: <871weops83.fsf@j228-gm.comp.glam.ac.uk> (raw)
In-Reply-To: <m3ir81juqp.fsf@codesourcery.com> (Jim Blandy's message of "Mon, 30 Jul 2007 17:13:18 -0700")
Jim Blandy <jimb@codesourcery.com> writes:
> I'd like to see the tests go in, too. I'm not sure the approach they
> take is one we'd like to follow in future code, though.
>
> I'm inferring from the test and from the Modula-2 code in GDB that
> the debugging information GCC emits for unbounded arrays claims that
> they're a structure of the form:
>
> struct {
> char *_m2_contents;
> int _m2_high;
> };
>
> Then, GDB's Modula-2 code recognizes this structure as a special case,
> and treats it as an array.
>
> It seems to me the tests should go ahead and require a Modula-2
> compiler, compile a real Modula-2 program, and exit with 'unsupported'
> if there's no Modula-2 compiler present.
>
> It's a shame that the debugging info doesn't actually treat these
> Modula-2 arrays as arrays. The 'proper' DWARF representation would be
> a DW_TAG_array_type die with a DW_TAG_subrange_type for the variable
> index whose a DW_AT_upper_bound attribute is some DWARF expression
> like:
>
> DW_OP_push_object_address DW_OP_lit4 DW_OP_plus DW_OP_deref
>
> to compute the upper bound of the array.
>
> Then GDB would need to learn to understand these things. In a
> quick-and-dirty implementation, the DWARF reader would turn the DWARF
> above into arrays whose index subrange types used a new
> BOUND_BY_DESCRIPTOR value for 'enum array_bound_type', ignoring the
> DWARF expression. Then language-specific code would have to handle
> those as a special case.
>
> The best implementation would be to have a new BOUND_COMPUTED style of
> bound, and have the 'loc' union in 'struct field' point to a structure
> like this:
>
> struct computed_bound {
> /* Return the value of a computed bound. V is the array value whose
> bound we're computing; CB is a pointer to this structure. */
> LONGEST (*compute_bound (struct computed_bound *cb, struct value *v));
>
> /* Data to be used by the COMPUTE_BOUND function. */
> void *data;
> };
>
> The DWARF reader would create these when it sees arrays with upper
> bounds that are expressions, making DATA point to the expression and
> COMPUTE_BOUND point to a function that uses dwarf2expr.h to evaluate
> the expression.
>
> Then the generic GDB array code could handle Modula-2 variable arrays
> (or anything else that the DWARF described accurately).
>
> This isn't exactly a one-weekend project, though.
Hi Jim,
thank you for the various pointers (re: dwarf2 opcodes, subranges and
unbounded arrays - I also note your --fixme-- in the dwarf2read code)
- I wonder whether it might be better to hold off applying the patch
and attempt to solve the problem properly using the COMPUTE_BOUND
method explained above. I'm willing to attempt this - its always more
satisfying solving a problem correctly :-) and in theory this method
might be useful for Pascal as well. It should also mean ISO M2
multidimensional unbounded arrays will be easier to implement.
regards,
Gaius
next prev parent reply other threads:[~2007-07-31 14:29 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-26 7:07 Gaius Mulley
2007-07-26 7:36 ` Markus Deuling
2007-07-27 12:26 ` Gaius Mulley
2007-07-27 20:22 ` Eli Zaretskii
2007-07-30 8:29 ` Gaius Mulley
2007-07-30 23:34 ` Jim Blandy
2007-07-31 3:01 ` Jim Blandy
2007-07-31 16:47 ` Gaius Mulley [this message]
2007-07-31 16:48 ` Jim Blandy
2007-08-01 14:01 ` Gaius Mulley
2007-07-31 19:18 ` Jim Blandy
2007-10-16 16:59 ` Gaius Mulley
2007-10-16 22:04 ` Jim Blandy
2007-07-26 22:58 ` Pierre Muller
2007-07-27 13:17 ` Gaius Mulley
2007-07-27 13:28 ` Pierre Muller
2007-07-28 0:59 ` Jim Blandy
2007-07-30 6:29 ` Gaius Mulley
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=871weops83.fsf@j228-gm.comp.glam.ac.uk \
--to=gaius@glam.ac.uk \
--cc=deuling@de.ibm.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sources.redhat.com \
--cc=jimb@codesourcery.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