From patchwork Tue Nov 18 13:33:13 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ilya Enkovich X-Patchwork-Id: 412039 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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 1E7C5140174 for ; Wed, 19 Nov 2014 00:33:51 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; q=dns; s=default; b=PSulS/2BgpErHomhJZ 6ytczReJQ3L0cRPXszQexb5Vnv94LpI9NXFMn+7kig80/zUwTio1GXvE5tzk8aqo NFmVTPiAIYQzE++aOo+iLkaysgntAW1eCGRaG3zv2aiKvohtdvcwS3tQsK29tZ6N XwldOziPXdmLy69PVqUpT7RGI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; s=default; bh=Y6wtx+U0j4O/uehiD4gnyOum VtY=; b=yZak1o0T1K8ZBfJKfrUhZ4aK4SQZEvI6Ew8VIAqBYvTC7HBeB6Mj/R/d ZdRR2QrRnOEJVFreykk4ThTGZ7T+pysMmkAoBm8czj7CXX08KgplfagIhBe8xHTq +mJdh3pdlgoICMCI9YpAj4uSIkrJEgsnqRApod9mBoz7YNbnBc4= Received: (qmail 18483 invoked by alias); 18 Nov 2014 13:33:18 -0000 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 Received: (qmail 18375 invoked by uid 89); 18 Nov 2014 13:33:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.5 required=5.0 tests=AWL, BAYES_50, FREEMAIL_FROM, LIKELY_SPAM_BODY, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-ie0-f175.google.com Received: from mail-ie0-f175.google.com (HELO mail-ie0-f175.google.com) (209.85.223.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 18 Nov 2014 13:33:15 +0000 Received: by mail-ie0-f175.google.com with SMTP id at20so8696185iec.34 for ; Tue, 18 Nov 2014 05:33:13 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.118.35 with SMTP id kj3mr33333514igb.30.1416317593353; Tue, 18 Nov 2014 05:33:13 -0800 (PST) Received: by 10.64.121.36 with HTTP; Tue, 18 Nov 2014 05:33:13 -0800 (PST) In-Reply-To: References: <546A414E.6040905@redhat.com> <546AB56C.3000902@redhat.com> Date: Tue, 18 Nov 2014 16:33:13 +0300 Message-ID: Subject: Re: [PATCH, Pointer Bounds Checker, Builtins instrumentation 3/5] Expand instrumented builtin calls From: Ilya Enkovich To: Richard Biener Cc: Jeff Law , David Edelsohn , GCC Patches X-IsSubscribed: yes 2014-11-18 15:18 GMT+03:00 Richard Biener : > On Tue, Nov 18, 2014 at 1:13 PM, Ilya Enkovich wrote: >> 2014-11-18 15:04 GMT+03:00 Richard Biener : >>> On Tue, Nov 18, 2014 at 11:51 AM, Ilya Enkovich wrote: >>>> 2014-11-18 5:56 GMT+03:00 Jeff Law : >>>>> On 11/17/14 13:43, Ilya Enkovich wrote: >>>>> >>>>>> >>>>>> I don't fully understand how this problem appears. Is it fully AIX >>>>>> specific and doesn't affect any other target? May we put all _CHKP >>>>>> codes to the end of enum and ignore them by AIX? Limiting number of >>>>>> codes in enum due to restrictions of specific debug info format seems >>>>>> weird. If something cannot be encoded for debug info then it should >>>>>> be ignored. I really hoped that creation of functions by demand would >>>>>> allow to avoid such kind of problems :( >>>>>> >>>>>> I'll try to make a patch reducing amound of builtin codes to a >>>>>> required minimum in case it appears to be the best option we have. >>>>> >>>>> It's a problem with the AIX native tools. Presumably they don't like really >>>>> long lines -- it was a relatively common issue in the past with vendor >>>>> tools. >>>>> >>>>> I think we should proceed on two fronts. First if David could investigate >>>>> the stabs-in-xcoff bits a bit to see if DBX_CONTIN_LEN can be used to >>>>> resolve the issue. Second if you could look at now duplicating every >>>>> builtin in the enumeration since it's a combination of the number of enums >>>>> and the length of the debug strings to represent them that's causing AIX >>>>> heartburn. >>>>> >>>>> >>>>> >>>>> jeff >>>> >>>> I see. I can reduce the number of _CHKP builtin codes. Experimental >>>> patch shows resulting END_BUILTINS = 1242. But we should expect >>>> similar problem for i386 target builds hosted on AIX (here >>>> http://toolchain.lug-owl.de/buildbot/ I see such build is tested). >>>> Current IX86_BUILTIN_MAX is 2467 which is greater than current >>>> END_BUILTINS. >>> >>> I think it's better to fix dbxout.c to do something sensible with >>> too long lines for enum types. It should be easy to cook up a >>> testcase that is not GCC. >>> >>> enum { entry1, entry2, entry3.... }; >>> >> >> As I understand the main problem is that fixing dbxout in trunk won't >> help to build stage1 compiler. > > Simply build stage1 without debug info on AIX then. > > Btw, you have to start fixing the bug at some point ... (we can > backport to 4.8 and 4.9). Of course dbxout.c is in kind of > deep-freeze unmaintained state. Seems with no continuation lines support there is no easy way to limit stabstring length. But it should be easy to fix this particular problem (too long stabstring due to many enum values) by discarding the rest of values when some string length threshold is hit. Possible patch: With this we should be able to set limit in target config files. Tried on linux with a small test with limit set to 20: >cat test.c enum e1 { val1, val2, val3 }; >gcc test.c -S -gstabs >grep e1 test.s .stabs "e1:T(0,21)=eval1:0,val2:1,;",128,0,0,0 The last enum value was discarded. I don't know which target should set this limit and what limit values should be used. Thanks, Ilya > > I don't think we ever encouraged work-arounds for broken host compilers > if that requires substantial work. > >>> not sure how exactly the issue breaks AIX bootstrap though. I suppose >>> the assembler complains? >> >> It is linker how complaints. Here is a build log example: >> http://toolchain.lug-owl.de/buildbot/deliver_artifact.php?mode=view&id=3073584 > > I see. > > Thanks, > Richard. > >> Ilya >> >>> >>> Richard. >>> >>>> Ilya diff --git a/gcc/dbxout.c b/gcc/dbxout.c index aa15a39..9b0b82d 100644 --- a/gcc/dbxout.c +++ b/gcc/dbxout.c @@ -168,6 +168,10 @@ along with GCC; see the file COPYING3. If not see #define DBX_CONTIN_CHAR '\\' #endif +#ifndef DBX_MAX_LENGTH +#define DBX_MAX_LENGTH 0 +#endif + enum typestatus {TYPE_UNSEEN, TYPE_XREF, TYPE_DEFINED}; /* Structure recording information about a C data type. @@ -2270,6 +2274,12 @@ dbxout_type (tree type, int full) stabstr_C (','); if (TREE_CHAIN (tem) != 0) CONTIN; + + /* Prevent too long strings rejected by linker. */ + if (DBX_CONTIN_LENGTH == 0 + && DBX_MAX_LENGTH != 0 + && obstack_object_size (&stabstr_ob) > DBX_MAX_LENGTH) + break; } stabstr_C (';');