From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10791 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: cortex-m support? Date: Mon, 12 Dec 2016 20:48:40 -0500 Message-ID: <20161213014840.GT1555@brightrain.aerifal.cx> References: <04e5a294-719e-8029-704f-a57d1ec935b0@landley.net> <20161207152936.GB16379@port70.net> <20161207153519.GC16379@port70.net> <20161208011625.GL1555@brightrain.aerifal.cx> <59e46cdf-0a51-7dd6-e299-dc4137ef91cc@landley.net> <20161208210114.GN1555@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1481593736 5626 195.159.176.226 (13 Dec 2016 01:48:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 13 Dec 2016 01:48:56 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-10804-gllmg-musl=m.gmane.org@lists.openwall.com Tue Dec 13 02:48:52 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1cGcD4-0000i1-IU for gllmg-musl@m.gmane.org; Tue, 13 Dec 2016 02:48:50 +0100 Original-Received: (qmail 26141 invoked by uid 550); 13 Dec 2016 01:48:53 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 26123 invoked from network); 13 Dec 2016 01:48:52 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10791 Archived-At: On Mon, Dec 12, 2016 at 06:29:13PM -0600, Rob Landley wrote: > > > On 12/08/2016 03:01 PM, Rich Felker wrote: > > On Thu, Dec 08, 2016 at 01:10:11PM -0600, Rob Landley wrote: > >> On 12/07/2016 07:16 PM, Rich Felker wrote: > >>> On Wed, Dec 07, 2016 at 06:55:56PM -0600, Rob Landley wrote: > >>>> Not sure where you get the relevant gcc patch... > >>> > >>> I have links to the repos somewhere; the problem is that they're > >>> forked from a fairly old gcc version (although not nearly as bad as > >>> sh-fdpic; I think it's 4.8 or so) > >> > >> https://github.com/mickael-guene/gcc has a 5.2 branch and "master" > >> updated 20 hours ago, although I'm not sure how much of master updating > >> is an automatic tracking branch and how much is the account owner > >> updating things. > > > > Excellent! That's new since I last communicated with him. > > In theory, what you do is follow the instructions in: > > https://github.com/mickael-guene/fdpic_manifest OK, I'll take a look. > Which uses repo to download the github repositories, and then has a > build.sh. In practice, I'm not sure what branches that uses to build > said toolchain. > > However, this would give you a uClibc-based cortex-m-fdpic toolchain you > could then swap musl into. Just diffing the tree and dropping the patch in musl-cross-make is going to be a much faster path to getting something reproducible and testable. > It also has a lsit of kernel patches that > theoretically work against vanilla, but you don't have a board for that. :) Can you get me (instructions for building) a kernel that boots on qemu but has the fdpic-support patches for arm? The main patch hunk that'll be needed is the part in signal handler invocation that uses the function pointer as either a code address or a function descriptor. BTW, upstreaming this patch without an old pending kernel change I still need to submit will introduce a CVE-worthy vulnerability on all ARM systems. :-) > I did poke you over the summer about running cortex-m binflt binaries > under qemu application emulation (works fine). I dunno if it supports > the fdpic loader or not, building this toolchain to find out. If not, > it's got an emulator there too but I haven't poked at it yet... It can load fdpic as normal ELF just fine, but signal handlers will crash if it doesn't treat the application-passed function pointer as a function descriptor. Fixing this should just be a several-line patch to qemu if nobody already did it. Rich