From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id OYT6L8nJn2qZljYAWB0awg (envelope-from ) for ; Tue, 08 Sep 2026 04:39:37 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=cebitec.uni-bielefeld.de header.i=@cebitec.uni-bielefeld.de header.a=rsa-sha256 header.s=20200306 header.b=WIK6Ok2l; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id BAE741E09E; Tue, 08 Sep 2026 04:39:37 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=unavailable autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id DE1391E091 for ; Tue, 08 Sep 2026 04:39:35 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A7EA44B920D6 for ; Tue, 8 Sep 2026 08:39:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A7EA44B920D6 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=cebitec.uni-bielefeld.de header.i=@cebitec.uni-bielefeld.de header.a=rsa-sha256 header.s=20200306 header.b=WIK6Ok2l Received: from smtp.CeBiTec.Uni-Bielefeld.DE (smtp.CeBiTec.Uni-Bielefeld.DE [129.70.160.84]) by sourceware.org (Postfix) with ESMTPS id D499E4BA23D1 for ; Tue, 8 Sep 2026 08:39:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D499E4BA23D1 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=CeBiTec.Uni-Bielefeld.DE Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cebitec.uni-bielefeld.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D499E4BA23D1 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=129.70.160.84 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1788856751; cv=none; b=n5yS/JFo5y5ISxq1Ace9+nmMzG6CetGeQn4gEY+6sQn00yuPnSIMqDYjRW/qkkcQ86XuHO9UQwBsuuEt84x+snMQhJKo7OX0d/qhGs1/eKzg58rBddNDh+tXhNKRhgQBNtXIcW26yrnIgbkrRU3+boi0e/DcH7r0xGoR4vAlYZM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1788856751; c=relaxed/simple; bh=vCW3aKSSmZi/8yKi7pKsJFUPrOXvTwOQxeZmnRsftJY=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=PeIQjZn7iNkFH8vAZamuWhAkWps8F/Rx5kq2mKnHy5gsgbdKT38sgalJiYJ4QNNVkTjiDYhC/fQVi/iGs21ncUWK8g7Fv7kbVCcTdNEBxWqn9OfuOxNVpbpcD2y2/IBzYexbO4aATMSGQuZMMp9YDdkUePg8Tvsa2bvz1fsoC/4= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=cebitec.uni-bielefeld.de header.i=@cebitec.uni-bielefeld.de header.a=rsa-sha256 header.s=20200306 header.b=WIK6Ok2l DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D499E4BA23D1 Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id F070EE35E2; Tue, 8 Sep 2026 10:39:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= cebitec.uni-bielefeld.de; h=content-type:content-type :mime-version:user-agent:message-id:date:date:references :in-reply-to:subject:subject:from:from:received:received; s= 20200306; t=1788856749; bh=vCW3aKSSmZi/8yKi7pKsJFUPrOXvTwOQxeZmn RsftJY=; b=WIK6Ok2l0rSwuzvW6z4yh8jVA9MqeaFxJlX7PVVKBeVLg42Ju8RDj NiLsoG6KZyJrbpEQQSQrzC4r7Gk+4gExolteG7bxB10Xs3t3Au4MkZP1Uq9Ikz2Y Z0ig6E8k7oku2mQQ6bHbtL7zYsIZgNgL92jdLgZgMk03saKdjWtJOa9OYUIFveNu IOlN4t0r6Pd6RizcvvhOsJAxY3a5jfxG3kEbHBrNSMv4aMcL2IPWb7MehAixbTOv 5btr8/yvEXzxPICr7pD1flfX6q+9aZQu2ostdW6baEUKMDuJz+bj1HsZMlBElq1w rhHYCjdaKPtjv3iXls+UbW9qYF3dx2gWA== X-Virus-Scanned: amavisd-new at cebitec.uni-bielefeld.de Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (smtp.cebitec.uni-bielefeld.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0udfy85PQ4ZY; Tue, 8 Sep 2026 10:39:09 +0200 (CEST) Received: from manam.CeBiTec.Uni-Bielefeld.DE (p50854206.dip0.t-ipconnect.de [80.133.66.6]) (Authenticated sender: ro) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPSA id 706D9E35E1; Tue, 8 Sep 2026 10:39:09 +0200 (CEST) From: Rainer Orth To: Andrew Burgess Cc: gdb-patches@sourceware.org, Simon Marchi Subject: Re: [PATCH] Reduce gdb.base/many-headers.c iterations on Solaris [PR34555] In-Reply-To: <87ik4hqgcq.fsf@redhat.com> (Andrew Burgess's message of "Mon, 07 Sep 2026 15:35:33 +0100") References: <87ik4hqgcq.fsf@redhat.com> Date: Tue, 08 Sep 2026 10:39:09 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Hi Andrew, > Rainer Orth writes: > > GDB doesn't usually place bug IDs in the subject line as you're doing > here. Instead bugs should be mentioned in the text, as you do, using > the 'PR component/number' syntax, then there should be a 'Bug: URL' tag > added at the end of the commit message. as I'd mentioned before, the once close cousins gcc, binutils, and gdb have diverged more and more over time, not only in such conventions. This is particularly confusing to occasional contributors... >> As detailed in PR corefiles/34555, when reading the core file in the >> gdb.base/many-headers.exp test, gdb consumes excessive amounts of memory >> on Solaris. If left unchecked, e.g. with ulimit -Sv 8388608, the test >> will consume all available swap space. Since Solaris doesn't do lazy >> allocation, this will cause the system to become unusably slow. >> >> To avoid this, this patch reduces the iteration count by a factor of 100. > > My issue with this change is that the point of the test is to create > many headers. If we reduce the header count then the test is no longer > doing what it says it is, and the whole test becomes, well, pointless. > > I wonder if it would be better to just add this near the top of the test > script: > > if {[istarget "*-*-solaris*"]} { > # The Solaris core file reader consumes excessive memory with many > # program headers (PR corefiles/34555). > kfail gdb/34555 $gdb_test_file_name > return > } Honestly I don't care: my primary point is preventing gdb make check from bringing down machines it is run on. > While looking at this I spotted that gdb.base/bigcore.exp already bails > out early for Solaris, I wonder if this is the same underlying issue? No directly AFAICS: for the unmodified many-headers.c test, the core dumps are 407 MB (amd64) or (sparcv9), but only consume 5.1 or 4.1 MB on disk. However, creating those core files alone is very slow: ca. 17 minutes. > The bug number mentioned in bigcore.exp (gdb/1551) is, I think, from > pre-bugzilla days, so I've not been able to track that to an actual bug > I could look at. That message goes back to the original test back in 2004, originally applying only to NetBSD, but having been extended to various other systems, including Solaris, shortly thereafter. I haven't searched for the patch submissions, though. However, if the test relies on Linux features, it might be better to restrict it to Linux rather than skipping it on more and more other systems. >> AFAICT, the issue is purely in gdb's Solaris corefile reader, which >> seems to need a complete rewrite rather than a couple of bugfixes. > > Having touched lots of core file stuff recently, I'd be interested to > know more about where exactly the problem is. I tried to get some Solaris corefile patches in the Solaris userland repo into shape for upstream submission back in 2018. When trying so, I found that the NT_PRSTATUS NOTE sections which are from the old ioctl-based procfs interface and the only ones handled by bfd/elf.c have been obsoleted and superceded by NT_PSTATUS ones introduced in Solaris 2.6 back in 1997 with the introduction of the new structured procfs. ISTM that Solaris corefile support needs a complete rewrite to deal with almost 30 years of neglect. Considering the general state of gdb on Solaris (3000+ testsuite failures, 400+ tests timing out during make check), corefile support is the very least of my concerns. I'm slowly reaching the same conclusion as 8 years ago when I abandoned those efforts: getting gdb into shape on Solaris is way beyond may abilities and time I'm able to invest. When trying to get binutils ready for setting up buildbots, it took me almost a year just analyzing the testsuite failures, which were only fixed with tons of help from both Alan Modra who did most of the actual fixes, and Ali Bahrami, the Solaris linker/ELF utilities maintainer, me at the time very much neglecting my GCC work. GDB seems an order of magnitude worse. Add to that the huge gdb codebase, an implemention language I know close to nothing about (highly idiomatic C++17), and several other factors, ISTM that the best I can achieve is getting buildbots up to make sure gdb at least compiles and passes the most basic of tests. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University