From patchwork Tue Sep 2 10:28:15 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans-Peter Nilsson X-Patchwork-Id: 385066 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 2883614018A for ; Tue, 2 Sep 2014 20:29:14 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :message-id:from:to:subject:mime-version:content-type :content-transfer-encoding; q=dns; s=default; b=wwUYa6CNNzkpxQ2N Oe2CUyGKBGpu5m5LXyrW48IpbcOZ/Mn5YBJzlYd8tUvFadr/wlBvKhG5UtCwLahj FKQOqgtvKrnTFJT2p51lndsGbxwiu6gVxu68qtie16HW8NcvoAIgLcvrROO7edbA JmYsd2zAw3n1N8xvRWx7GaxC3zA= 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:date :message-id:from:to:subject:mime-version:content-type :content-transfer-encoding; s=default; bh=TB8pz8eNWS0duNexTQpxFv Y9P24=; b=cDHyjrDVFBMyxF83iUvIOiYnHF7Hcc+O766uCqBhEM2WtwBGDiWRDv 8sBwCg+xucTumu+TUTK4ZZjdVEV7iBsdQG1Kfs4Rb+vDLCnTgv1SFxqAPvl6C/+j 9M/6B09vXpDAnLFFK9NyLX+YDQrMJmkrbaYyrzYA78UxcZE7A5YcY= Received: (qmail 28482 invoked by alias); 2 Sep 2014 10:28:24 -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 28421 invoked by uid 89); 2 Sep 2014 10:28:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 X-HELO: bastet.se.axis.com Received: from bastet.se.axis.com (HELO bastet.se.axis.com) (195.60.68.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 02 Sep 2014 10:28:22 +0000 Received: from localhost (localhost [127.0.0.1]) by bastet.se.axis.com (Postfix) with ESMTP id D62CD18074 for ; Tue, 2 Sep 2014 12:28:18 +0200 (CEST) Received: from bastet.se.axis.com ([IPv6:::ffff:127.0.0.1]) by localhost (bastet.se.axis.com [::ffff:127.0.0.1]) (amavisd-new, port 10024) with LMTP id KRVxRx+ozP6Y for ; Tue, 2 Sep 2014 12:28:16 +0200 (CEST) Received: from boulder.se.axis.com (boulder.se.axis.com [10.0.2.104]) by bastet.se.axis.com (Postfix) with ESMTP id B20011807B for ; Tue, 2 Sep 2014 12:28:16 +0200 (CEST) Received: from boulder.se.axis.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 915601049 for ; Tue, 2 Sep 2014 12:28:16 +0200 (CEST) Received: from thoth.se.axis.com (thoth.se.axis.com [10.0.2.173]) by boulder.se.axis.com (Postfix) with ESMTP id 819A4D9C for ; Tue, 2 Sep 2014 12:28:16 +0200 (CEST) Received: from ignucius.se.axis.com (ignucius.se.axis.com [10.88.21.50]) by thoth.se.axis.com (Postfix) with ESMTP id 7EC1434005; Tue, 2 Sep 2014 12:28:16 +0200 (CEST) Received: from ignucius.se.axis.com (localhost [127.0.0.1]) by ignucius.se.axis.com (8.12.8p1/8.12.8/Debian-2woody1) with ESMTP id s82ASGQD030063; Tue, 2 Sep 2014 12:28:16 +0200 Received: (from hp@localhost) by ignucius.se.axis.com (8.12.8p1/8.12.8/Debian-2woody1) id s82ASFsk030059; Tue, 2 Sep 2014 12:28:15 +0200 Date: Tue, 2 Sep 2014 12:28:15 +0200 Message-Id: <201409021028.s82ASFsk030059@ignucius.se.axis.com> From: Hans-Peter Nilsson To: gcc-patches@gcc.gnu.org Subject: [RFA:] testsuite: robustify g++.old-deja/g++.eh/badalloc1.C for 64-bit systems MIME-Version: 1.0 In a native x86_64-linux toolchain in which eh-table-registration is done explicitly (i.e. dl_iterate_phdr and PT_GNU_EH_FRAME is *not* assumed, as that eliminates the issue), the memory overhead for exception-initialization goes beyond the 32768 bytes assumed in badalloc1.C and the test fails for reasons not intended by the test. You may think that's uninteresting, but presumably there are other 64-bit-systems, perhaps even GNU-based, that act similarly. For EH tables registered with the __register_frame_info scheme (let's call it eh-registry as opposed to eh-phdr), the incoming tables are not assumed to be sorted. EH initialization then does an initial sorting at the first exception, in which there are calls to malloc for arrays for the sorted tables. This is noticable in badalloc1.C as it overrides malloc. All this happens at that first "try{fn_throw();}" with the related comment, i.e. before the "fail = 1" and the actual test in badalloc1.C. (There are other calls to malloc for other unrelated initialization tasks, but for glibc systems these resolve to a malloc in the dynamic linker.) The sequence of calls to malloc in badalloc1.C go like this: Size Purpose Function name 132 Core exception data. __cxxabiv1::__cxa_allocate_exception 88 EH table for "badalloc1" start_fde_sort program, 9 FDE:s for the " (ditto) "linear" table. " 88 Ditto the "erratic" table. " 19176 Similar 2395 FDE:s for the " libstdc++ library, "linear". " 19176 Ditto the "erratic" table. " *boom* The "boom" is simply the arena size check failing in the badalloc1.C malloc: // Verify that we didn't run out of memory before getting initialized. if (pos > arena_size) abort (); It seems the arena_size=32768 bytes estimate was from the 32-bit-systems era (svn logs indicate 2000). Just scaling it accordingly works fine, and we get to see the rest of the allocations: 1344 166 FDE:s in libgcc_s, "linear" table 1344 Ditto "erratic". For a -m32 run, the corresponding allocation-size series is 100, 66, 66, 9592, 9592, 648, 648. (*) for one reason or another. Maybe the GNU linker is not used or *really* outdated (before 2001-12-13, 2.12) or glibc is *really* outdated (before 2001-07-25, 2.2.4). Or inhibit_libc accidentally set, or a compatibility scheme forcing eh-registry. More about that in a later post. Having investigated the related test-suite failure, I suggest to eliminate it by robustifying the arena size a bit (or 32 :). I don't touch the other arena_size definitions because (1) those numbers are presumably already fine for the related systems, those still alive, and (2) I don't like changing stuff I cannot test. Other observations: I guess there are similar copyright notices in the test-suite may need some general attention. The xfail list may benefit from tweaking; at least replacing the xstormy16 with int32plus or similar to cover the array size overflowing 16-bit addresses. Ok to commit? (Note the changelog-conditional-prefix continued-line format.) gcc/testsuite: * g++.old-deja/g++.eh/badalloc1.C [!STACK_SIZE && !__FreeBSD__] [!__sun__ && !__hpux__] (arena_size): Scale according to target pointer size. brgds, H-P Index: g++.old-deja/g++.eh/badalloc1.C =================================================================== --- g++.old-deja/g++.eh/badalloc1.C (revision 214810) +++ g++.old-deja/g++.eh/badalloc1.C (working copy) @@ -3,7 +3,7 @@ // itself call malloc(), and will fail if there is no more // memory available. // { dg-do run { xfail { { xstormy16-*-* *-*-darwin[3-7]* } || vxworks_rtp } } } -// Copyright (C) 2000, 2002, 2003, 2010, 2012 Free Software Foundation, Inc. +// Copyright (C) 2000, 2002, 2003, 2010, 2012, 2014 Free Software Foundation, Inc. // Contributed by Nathan Sidwell 6 June 2000 // Check we can throw a bad_alloc exception when malloc dies. @@ -23,7 +23,10 @@ const int arena_size = 256; // FreeBSD 5 now requires over 131072 bytes. const int arena_size = 262144; #else -const int arena_size = 32768; +// Because pointers make up the bulk of our exception-initialization +// allocations, we scale by the pointer size from the original +// 32-bit-systems-based estimate. +const int arena_size = 32768 * ((sizeof (void *) + 3)/4); #endif #endif