Re: cortex-m support?

[Rob Landley <rob@landley.net>]

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.
> 
>>> and the authors probably don't have
>>> copyright assignments taken care of.
>>
>> Nobody does copyright assignments voluntarily. In the long run those
>> kill projects.
> 
> I don't want to start an unrelated GNU-politics thread, but...
>...
> In my opinion this is 100% the FSF's fault for creating such a broken
> system, but it's the reality.

More or less what I meant, yes.

Keep in mind gcc development -already_ died once (egcs), and the lesson
the llvm guys learned is "don't fork off the old dead base, even if it's
been dead for years it's poison and they'll steal it back if you get it
going again, instead start over from scratch with something they have no
claim to".

> So people who modify GNU stuff and who do want their work
> to live on and be useful in the future

already screwed up before the "and"; everything else is damage control.

> This is really good news -- I think adding the patches should be easy.
> You can probably just diff his tree against stock 5.2.0 and make it
> one big combined patch. This makes getting stuff ready on the musl
> side a lot more attractive to me, so I will try to get back to is
> asap.

FYI, the cortex-m toolchain I've been building (which builds a kernel
and userspace that runs on the board) is just buildroot's cortex-m
toolchain.

Grab current buildroot, "make defconfig" then "make menuconfig" and:

  target options -> target architecture -> arm little endian
  target options -> target architecture variant -> cortex-m3
  build options -> host dir (set to /opt/arm-linux)
  toolchain->enable c++ support

Then "sudo make" (so it can write to /opt/arm-linux).

The version of buildroot I had needed to do "ln -s arm-linux-ld.real
/opt/arm-linux/usr/bin/ld.real" because the binflt wrapper is broken and
evil, but maybe that's fixed upstream since? And the buildroot commit
history disables -Os on cortex-m due to some compiler bug (maybe fixed
now? Haven't hit it myself but I build with -O2 instead for this board
on general principles.)

Oh, and there's a separate "Enable elf2flt support" config thing in the
toolchain menu that you DON'T want to select or it'll wrap the toolchain
_twice_ and break, buildroot does it automatically for cortex-m. I think
it's even a magic wrapper doing the -Wl,-elf2flt stuff automatically. :)

> Rich
> .

Rob