Re: cortex-m support?

[Rich Felker <dalias@libc.org>]

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