From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Subject: [RFA/DWARF] Set TYPE_FLAG_STUB for enum DIEs that are declarations only
Date: Thu, 03 Jan 2008 15:45:00 -0000 [thread overview]
Message-ID: <20080103153952.GC582@adacore.com> (raw)
Long explaination but small patch :-).
For those who are not familiar with Ada, the declaration of types
whose implementation must be opaque is done as follow:
type My_Opaque type is private;
And then the language expects that you provide the definition
of that type in the private section of your package spec, like so:
private
type My_Opaque is (One, Two, Three);
But there has been a small amendment to that which allows a developer
to provide the actual definition not in the spec, but in the body.
This is an approach that is not used very often, but still legitimate.
These types are called "Taft Amendment Types" (TAT) because they were
introduced by Tucker Taft, I believe.
Unfortunately, we found out that this can cause trouble in the debugger.
When compiling a unit that uses a TAT, the compiler does not look
inside the package body, but only in the package spec. So it knows that
we have an object of that type, but it doesn't know what that type is.
As a result, it generates a bogus "stub" enumeration type and sets
its AT_declaration attribute. The debugger missed that part, and so
we ended up thinking that our object was a degenerated enum type,
and printed its value accordingly:
(gdb) p w.e.all
$1 = 0
The expected output is:
(gdb) p w.e.all
$1 = (month => 8, year => 1974)
The fix is to flag the type as a TYPE_FLAG_STUB, so that we will
know to lookup the complete definition.
2008-01-03 Joel Brobecker <brobecker@adacore.com>
* dwarf2read.c (read_enumeration_type): Flag type as stub if
the given die is a declaration.
I also wrote a small testcase that reproduces the issue:
2008-01-03 Joel Brobecker <brobecker@adacore.com>
* gdb.ada/taft_type/pck.ads, gdb.ada/taft_type/pck.adb,
gdb.ada/taft_type/p.adb: New files.
* gdb.ada/taft_type.exp: New testcase.
Tested on x86-linux. No regression.
OK to apply?
Thanks,
--
Joel
next reply other threads:[~2008-01-03 15:45 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-03 15:45 Joel Brobecker [this message]
2008-01-03 15:46 ` Joel Brobecker
2008-01-03 16:02 ` Daniel Jacobowitz
2008-01-03 17:38 ` Joel Brobecker
2008-01-05 12:33 ` Eli Zaretskii
2008-01-05 15:05 ` Joel Brobecker
2008-01-05 15:17 ` Eli Zaretskii
2008-01-05 15:37 ` Joel Brobecker
2008-01-08 5:57 ` Joel Brobecker
2008-01-08 20:25 ` Eli Zaretskii
2008-01-09 4:31 ` Joel Brobecker
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=20080103153952.GC582@adacore.com \
--to=brobecker@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