From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= Date: Sat, 21 Apr 2018 18:00:01 +0100 Subject: [U-Boot] [PATCH v2 2/2] arm: Make arch specific memcpy thumb-safe. In-Reply-To: <9B559474-B6A4-4D85-AD86-76F913F55CFF@theobroma-systems.com> ("Christoph \=\?iso-8859-1\?Q\?M\=FCllner\=22's\?\= message of "Sat, 21 Apr 2018 18:45:41 +0200") References: <20180420195144.32900-1-klaus.goger@theobroma-systems.com> <20180420195144.32900-3-klaus.goger@theobroma-systems.com> <9B559474-B6A4-4D85-AD86-76F913F55CFF@theobroma-systems.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de Christoph Müllner writes: >> On 21 Apr 2018, at 15:24, Måns Rullgård wrote: >> >> Klaus Goger writes: >> >>> The current arch implementation of memcpy cannot be called >>> from thumb code, because it does not use bx instructions on return. >>> This patch addresses that. Note, that this patch does not touch >>> the hot loop of memcpy, so performance is not affected. >>> >>> Tested on MXS (arm926ejs) with and without thumb-mode enabled. >>> >>> Signed-off-by: Klaus Goger >>> Signed-off-by: Christoph Muellner >> >> There are many more instances of mov to pc that ought to be fixed too. >> Why not do them all at once rather than picking them off one by one as >> they happen to break things? > > I could not find exit points within memcpy other than those which we fixed. > The many other mov pc, $lr instructions are just branches within memcpy. > Am I overseeing anything here? I meant elsewhere, not just in memcpy. -- Måns Rullgård