Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Cc: Jan Kratochvil <jan.kratochvil@redhat.com>
Subject: [RFA/RFC/dwarf] detect 0xffffffff size attribute values
Date: Thu, 19 Jun 2008 03:58:00 -0000	[thread overview]
Message-ID: <20080619033241.GA3568@adacore.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

Hello,

This an attempt to guard against a compiler bug:

    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35998

I know that Olivier and Eric told me that they committed some changes
in gigi that should fix some of the problems, but I don't know if this
one is already fixed on not. If someone does a build from HEAD could
tell me, that'd be great.

In any case, to help handling older versions of the compiler,
I propose we install a guard against -1 size attributes, which
get encoded as 0xffffffff.  When we detect this size attribute
value, we pretend we actually read 0.  This avoids attempting
to make a huge memory allocation when trying to create a value
of the associated type.

Jan, could you check whether this fixes the problem you saw?

2008-06-19  Joel Brobecker  <brobecker@adacore.com>

        * dwarf2read.c (read_attribute_value): Treat size attribute
        values of 0xffffffff as if the attribute value was zero.

Tested on x86-linux (both the standard regression testsuite and
the AdaCore regression testsuite). No regression.

What do you think? I know Daniel said during one of our conversations
that the idea itself is reasonable, but does the implementation look
OK to you?

Thanks,
-- 
Joel

[-- Attachment #2: dwarf2read.c.diff --]
[-- Type: text/plain, Size: 854 bytes --]

Index: dwarf2read.c
===================================================================
--- dwarf2read.c	(revision 132585)
+++ dwarf2read.c	(working copy)
@@ -6487,6 +6487,18 @@ read_attribute_value (struct attribute *
 	     dwarf_form_name (form),
 	     bfd_get_filename (abfd));
     }
+
+  /* We have seen instances where the compiler tried to emit a byte
+     size attribute of -1 which ended up being encoded as an unsigned
+     0xffffffff.  Although 0xffffffff is technically a valid size value,
+     an object of this size seems pretty unlikely so we can relatively
+     safely treat these cases as if the size attribute was invalid and
+     treat them as zero by default.  */
+  if (attr->name == DW_AT_byte_size
+      && form == DW_FORM_data4
+      && DW_UNSND (attr) >= 0xffffffff)
+    DW_UNSND (attr) = 0;
+
   return info_ptr;
 }
 

             reply	other threads:[~2008-06-19  3:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-19  3:58 Joel Brobecker [this message]
2008-06-19 13:56 ` Jan Kratochvil
2008-06-26 13:45 ` Daniel Jacobowitz
2008-06-26 20:11   ` Joel Brobecker
2008-06-26 20:19     ` Daniel Jacobowitz
2008-06-26 23:26       ` Joel Brobecker
2008-06-27  0:15         ` Daniel Jacobowitz
2008-06-27 18:20           ` 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=20080619033241.GA3568@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@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