From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19378 invoked by alias); 12 Apr 2010 01:54:30 -0000 Received: (qmail 17455 invoked by uid 48); 12 Apr 2010 01:54:16 -0000 Date: Mon, 12 Apr 2010 01:54:00 -0000 Message-ID: <20100412015416.17454.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4 In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "howarth at nitro dot med dot uc dot edu" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-04/txt/msg01100.txt.bz2 ------- Comment #8 from howarth at nitro dot med dot uc dot edu 2010-04-12 01:54 ------- The response from the dsymutil maintainer was... The warning was cause for alarm, and the root cause has been fixed (checked in), though it isn't affecting your test case. If you see this type of warning again before you get a fixed dsymutil, look at the dwarfdump output as you were doing for a matching attribute value. In this case it was: 0x00000205: TAG_subrange_type [28] AT_type[FORM_ref4] ( {0x00000048} ( base ) ) AT_upper_bound[FORM_ref4] ( {0x00000149} ) Then you want to make sure that the reference (FORM_ref4) it has ({0x00000149}) made it into the output file which it did: 0x00000149: TAG_variable [21] AT_artificial[FORM_flag] ( 0x01 ) AT_type[FORM_ref4] ( {0x0000020f} ( const base ) ) AT_location[FORM_data4] ( 0x00000144 0x0000000100000d46 - 0x0000000100000e62: r13-1 0x0000000100000e64 - 0x0000000100000e6f: r13-1 ) So everything is ok in this case. dsymutil will track exactly which DIEs make it into the dSYM and only put those DIEs and the dependent DIEs. This helps deal with gcc's one definition rule which can bloat up the debug info. If dead code stripping is on, and only one function of 100 makes it into the dSYM, we strip 99% of the debug info and keep the DWARF small. In a failing case, dsymutil would not add 0x00000149 to the output dSYM and the DWARF would have a DIE with an invalid reference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43254