From patchwork Wed Jan 4 18:09:02 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 134312 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id C1A0C1007D6 for ; Thu, 5 Jan 2012 05:09:28 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1326305370; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To: MIME-Version:Content-Type:Content-Disposition:User-Agent: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=tfjwscnSOGecPCsJBqQD 0V3pzZ8=; b=U2+9cTi/rxX9gj0jf/A2IEPQRGvz+GYiUiiK2CjLi6nvaOUVKH9w 8NW+LR5x1qC8kaebS5Ur3EdOrvmzjjC2fl5H0GFxiq2tyKZgyfMPWikXl5fAU0V+ N0fPOieGu3AZnF9opgyW+g0tvdZEX7CxHMgzzAwoQmyNHfnGhBhcGyM= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:MIME-Version:Content-Type:Content-Disposition:User-Agent:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=YuzYQtVKOwVifaA2aI71teXP7ZQjeDYwEgSX0JUImmR8Jbwo9LaQIlCZ21FAAO 1lJe/iW0fWdlQTF139CDqG457ve/5Vd90fEKZc2+WS8K5/3wVHEnDKdAOSc086yK QmSuvasRNFLFHNIFQQCvQgWRPqmbN8tOGSBEl6h7vYvPM=; Received: (qmail 25656 invoked by alias); 4 Jan 2012 18:09:22 -0000 Received: (qmail 25643 invoked by uid 22791); 4 Jan 2012 18:09:20 -0000 X-SWARE-Spam-Status: No, hits=-7.7 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Jan 2012 18:09:04 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q04I93Jh009636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 4 Jan 2012 13:09:04 -0500 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [10.16.42.4]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q04I936o030311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jan 2012 13:09:03 -0500 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [127.0.0.1]) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4) with ESMTP id q04I92DJ005934; Wed, 4 Jan 2012 19:09:02 +0100 Received: (from jakub@localhost) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4/Submit) id q04I926I005933; Wed, 4 Jan 2012 19:09:02 +0100 Date: Wed, 4 Jan 2012 19:09:02 +0100 From: Jakub Jelinek To: Richard Henderson , Jason Merrill , Alexandre Oliva Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Don't ICE on >= 64KB expressions in dwarf2out (PR debug/51695) Message-ID: <20120104180902.GE18937@tyan-ft48-01.lab.bos.redhat.com> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Hi! .debug_loc section format only uses 2 byte long size field for expressions, therefore we can't emit >= 64KB expressions. Unfortunately from time to time we do generate them, I hope Alex will look at how to prevent that from happening at var-tracking time, but still this isn't something we should assert on. The following patch drops them on the floor, it is questionable how much useful would they be compared to their huge size, another alternative would be to create DW_TAG_dwarf_procedure for them or for portions thereof (for subexpressions it would be even a potential nice debug info shrinking method, but would mean a lot of work and gdb support isn't there yet). So, for the time being I'm suggesting to just don't emit anything. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2012-01-04 Jakub Jelinek PR debug/51695 * dwarf2out.c (output_loc_list): For now drop >= 64KB expressions in .debug_loc on the floor. * gcc.dg/pr51695.c: New test. Jakub --- gcc/dwarf2out.c.jj 2012-01-03 16:22:48.000000000 +0100 +++ gcc/dwarf2out.c 2012-01-04 16:01:19.522191886 +0100 @@ -8166,6 +8166,13 @@ output_loc_list (dw_loc_list_ref list_he /* Don't output an entry that starts and ends at the same address. */ if (strcmp (curr->begin, curr->end) == 0 && !curr->force) continue; + size = size_of_locs (curr->expr); + /* If the expression is too large, drop it on the floor. We could + perhaps put it into DW_TAG_dwarf_procedure and refer to that + in the expression, but >= 64KB expressions for a single value + in a single range are unlikely very useful. */ + if (size > 0xffff) + continue; if (!have_multiple_function_sections) { dw2_asm_output_delta (DWARF2_ADDR_SIZE, curr->begin, curr->section, @@ -8184,7 +8191,6 @@ output_loc_list (dw_loc_list_ref list_he "Location list end address (%s)", list_head->ll_symbol); } - size = size_of_locs (curr->expr); /* Output the block length for this list of location operations. */ gcc_assert (size <= 0xffff); --- gcc/testsuite/gcc.dg/pr51695.c.jj 2012-01-04 16:04:51.990964287 +0100 +++ gcc/testsuite/gcc.dg/pr51695.c 2012-01-04 16:03:16.000000000 +0100 @@ -0,0 +1,52 @@ +/* PR debug/51695 */ +/* { dg-do compile { target { int32plus } } } */ +/* { dg-options "-O2 -g" } */ + +typedef struct +{ + struct { unsigned int t1, t2, t3, t4, t5, t6; } t; + int p; + struct { double X, Y, Z; } r; +} T; +typedef struct { T *h; } S; + +static unsigned int v = 0x12345678; + +int +foo (void) +{ + v = (v & 0x80000000) ? ((v << 1) ^ 0xa398655d) : (v << 1); + return 0; +} + +double +bar (void) +{ + unsigned int o; + v = (v & 0x80000000) ? ((v << 1) ^ 0xa398655d) : (v << 1); + o = v & 0xffff; + return (double) o / 32768.0; +} + +int +baz (void) +{ + foo (); + return 0; +} + +void +test (S *x) +{ + T *t = x->h; + t->t.t1 = foo (); + t->t.t2 = foo (); + t->t.t3 = foo (); + t->t.t4 = foo (); + t->t.t5 = foo (); + t->t.t6 = foo (); + t->p = baz (); + t->r.X = bar (); + t->r.Y = bar (); + t->r.Z = bar (); +}