From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 54D5E3857C4F for ; Mon, 19 Oct 2020 16:30:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 54D5E3857C4F Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A99311FB; Mon, 19 Oct 2020 09:30:29 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2042C3F66B; Mon, 19 Oct 2020 09:30:29 -0700 (PDT) Date: Mon, 19 Oct 2020 17:30:26 +0100 From: Dave Martin To: Florian Weimer Cc: Dave Martin via Libc-alpha , Joseph Myers Subject: Re: V5 [PATCH] sysconf: Add _SC_MINSIGSTKSZ/_SC_SIGSTKSZ [BZ #20305] Message-ID: <20201019163025.GQ32292@arm.com> References: <20201010121935.3263605-1-hjl.tools@gmail.com> <20201014174659.GL32292@arm.com> <87d01kk7fa.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87d01kk7fa.fsf@oldenburg2.str.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 16:30:31 -0000 On Wed, Oct 14, 2020 at 08:07:37PM +0200, Florian Weimer via Libc-alpha wrote: > * Dave Martin via Libc-alpha: > > > (Random, unrelated question ^^ is the missing "0x" on AT_HWCAP > > and AT_NOTELF intentional? Are we just stuck with those now?) > > I think it would make sense to file a bug in Bugzilla for that. OK > > Also, I discovered while trying to test my version of this that invoking > > ld.so explicitly messes up the auxv passed to the target program, > > probably as a side-effect of mungeing the args and environment. This > > leads to getauxval () returning garbage in the target program. > > > > Should I throw that in bugzilla, or is it likely to be trivial to sort > > out? > > I think this is: > > > > It's been open for two years, so it's probably fair to say that it is > not trivial to sort out. Purely empirically speaking. Ah, so long as it's not been forgotten about. I think I bugged Szabolcs about this when I first hit it, which probably explains where that ticket came from. Cheers ---Dave