From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1282 invoked by alias); 19 Jun 2008 03:33:33 -0000 Received: (qmail 1272 invoked by uid 22791); 19 Jun 2008 03:33:32 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 19 Jun 2008 03:33:05 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 8D74B1E830D; Wed, 18 Jun 2008 23:33:03 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lqNMo6Doq-vY; Wed, 18 Jun 2008 23:33:03 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 455CB1E82EF; Wed, 18 Jun 2008 23:33:03 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 9F3F5E7ACD; Wed, 18 Jun 2008 23:32:41 -0400 (EDT) Date: Thu, 19 Jun 2008 03:58:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Cc: Jan Kratochvil Subject: [RFA/RFC/dwarf] detect 0xffffffff size attribute values Message-ID: <20080619033241.GA3568@adacore.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-06/txt/msg00343.txt.bz2 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1220 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 * 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 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dwarf2read.c.diff" Content-length: 854 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; } --ikeVEW9yuYc//A+q--