From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [216.12.86.13]) by sourceware.org (Postfix) with ESMTPS id 2A9793861030 for ; Fri, 22 Jan 2021 18:31:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2A9793861030 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dalias@libc.org Date: Fri, 22 Jan 2021 13:31:27 -0500 From: Rich Felker To: Florian Weimer , musl@lists.openwall.com, libc-alpha@sourceware.org, linuxppc-dev@lists.ozlabs.org, Nicholas Piggin , Alan Modra Subject: Re: [musl] Re: [PATCH v2] powerpc/64/signal: balance return predictor stack in signal trampoline Message-ID: <20210122183127.GQ23432@brightrain.aerifal.cx> References: <20200511101952.1463138-1-npiggin@gmail.com> <87im7pp5yl.fsf@oldenburg.str.redhat.com> <20210122144402.GP23432@brightrain.aerifal.cx> <20210122181922.pcxyomeg5xcf2umu@work-tp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210122181922.pcxyomeg5xcf2umu@work-tp> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no 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: Fri, 22 Jan 2021 18:31:29 -0000 On Fri, Jan 22, 2021 at 03:19:22PM -0300, Raoni Fassina Firmino wrote: > On Fri, Jan 22, 2021 at 09:44:05AM -0500, Rich Felker wrote: > > Maybe I'm missing something but I don't see how this would break musl; > > we just inspect the PC in the mcontext, which I don't see any changes > > to and which should still point to the next instruction of the > > interrupted context. I don't have a test environment though so I'll > > have to wait for feedback from ppc users to be sure. Are there any > > further details on how it's breaking glibc? > > For glibc, backtrace() compares the return-address from each stack frame > to the value of `__kernel_sigtramp_rt64` to identify the frame with the > mcontext information, but now the return-address is not the start of the > routine, but the middle of it, so it fails to catch this special frame. Is there a reason it's backtracing rather than just looking at the interrupted context (pointed to by the third argument to the signal handler)? Rich