From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Subject: Re: [RFA/DWARF] Set enum type "flag_enum" and "unsigned" flags at type creation.
Date: Wed, 26 Feb 2014 18:58:00 -0000 [thread overview]
Message-ID: <20140226185813.GH4348@adacore.com> (raw)
In-Reply-To: <20140226183157.GF4348@adacore.com>
[-- Attachment #1: Type: text/plain, Size: 174 bytes --]
> I'll add a comment in the code...
Attached is the patch adding the comment...
gdb/ChangeLog:
* dwarf2read.c (read_subrange_type): Add comment.
Thanks,
--
Joel
[-- Attachment #2: 0001-Add-comment-in-dwarf2read.c-read_subrange_type.patch --]
[-- Type: text/x-diff, Size: 1810 bytes --]
From dbb9c2b1f231262ece36790241fe1fc3902cf03d Mon Sep 17 00:00:00 2001
From: Joel Brobecker <brobecker@adacore.com>
Date: Wed, 26 Feb 2014 10:53:05 -0800
Subject: [PATCH] Add comment in dwarf2read.c::read_subrange_type
This comment explains why we sometimes sign-extend the range type
bounds when we normally shouldn't have to.
gdb/ChangeLog:
* dwarf2read.c (read_subrange_type): Add comment.
---
gdb/ChangeLog | 4 ++++
gdb/dwarf2read.c | 7 +++++++
2 files changed, 11 insertions(+)
diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 8f2f0dc..49d8113 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,5 +1,9 @@
2014-02-27 Joel Brobecker <brobecker@adacore.com>
+ * dwarf2read.c (read_subrange_type): Add comment.
+
+2014-02-27 Joel Brobecker <brobecker@adacore.com>
+
* dwarf2read.c (update_enumeration_type_from_children): New
function, mostly extracted from process_structure_scope.
(read_enumeration_type): Call update_enumeration_type_from_children.
diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c
index 00bba47..52208d6 100644
--- a/gdb/dwarf2read.c
+++ b/gdb/dwarf2read.c
@@ -14522,6 +14522,13 @@ read_subrange_type (struct die_info *die, struct dwarf2_cu *cu)
}
}
+ /* Normally, the DWARF producers are expected to use a signed
+ constant form (Eg. DW_FORM_sdata) to express negative bounds.
+ But this is unfortunately not always the case, as witnessed
+ with GCC, for instance, where the ambiguous DW_FORM_dataN form
+ is used instead. To work around that ambiguity, we treat
+ the bounds as signed, and thus sign-extend their values, when
+ the base type is signed. */
negative_mask =
(LONGEST) -1 << (TYPE_LENGTH (base_type) * TARGET_CHAR_BIT - 1);
if (!TYPE_UNSIGNED (base_type) && (low & negative_mask))
--
1.8.3.2
next prev parent reply other threads:[~2014-02-26 18:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-27 8:09 Joel Brobecker
2014-02-10 14:29 ` Joel Brobecker
2014-02-17 20:20 ` Joel Brobecker
2014-02-19 14:34 ` Mark Wielaard
2014-02-19 15:18 ` Mark Wielaard
2014-02-21 9:21 ` Joel Brobecker
2014-02-25 14:32 ` Mark Wielaard
2014-02-26 18:32 ` Joel Brobecker
2014-02-26 18:58 ` Joel Brobecker [this message]
2014-02-27 10:30 ` Mark Wielaard
2014-02-27 11:15 ` Mark Wielaard
2014-02-27 14:29 ` Joel Brobecker
2014-02-26 18:42 ` pushed: " 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=20140226185813.GH4348@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