From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27981 invoked from network); 22 Jan 2021 18:31:43 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 22 Jan 2021 18:31:43 -0000 Received: (qmail 24221 invoked by uid 550); 22 Jan 2021 18:31:40 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 24197 invoked from network); 22 Jan 2021 18:31:39 -0000 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 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) Subject: Re: [musl] Re: [PATCH v2] powerpc/64/signal: balance return predictor stack in signal trampoline 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