[PATCH] Make Bitrig/ARM use Itanium-ABI

[Renato Golin]

On 19 February 2015 at 19:50, Patrick Wildt <mail at patrick-wildt.de> wrote:
> I actually might have a bit more, but I haven't yet found time to take
> care of creating patchsets and proper tests. I had some time and
> motivation today.

That's ok. What we need to do is to understand how all patches relate
to each other. Since this is a big change, the best thing would be to
know all patches to all components in advance, so we know what depends
on what, because we're not testing in the same way you are, and
inconsistencies can come from that.

Also, I'd prefer one patch per component, since there is only one
motivation behind all of them and juggling with multiple patches per
component won't help.


> I have pushed all my current changes to Github.  There's a commit
> at this link[0] which shows all changes we do to LLVM/Clang-vanilla.

Getting patches from github are not trivial with multiple trees. I'd
recommend you to base your changes on the official git repositories
and work in one branch per component.


>  * The Memory.inc change needs to be looked at. It got in at some point
>    to make ARM build, but I'm not sure it's quite right. Iirc
>    __clear_cache is provided by our compiler-rt...

It is. Let's make sure it's still needed.


>  * ARMMCAsmInfo change was send in today.

Got that.


>  * I don't know what the Options.td check is for, I need to understand
>    that.

That looks odd, as -pg outputs in the gprof format, while -p in "prof"
format (which I never used and don't know what the difference is). Not
sure why you needed that, but probably you don't any more.


>  * Parts of Targets were send in today. Additionally we might want to
>    get the __OpenBSD__ define in. We kept it out as we wanted to stop
>    defining __OpenBSD__ in the future, but so far there are definite
>    plans when and how to get rid of it. Currently it's rather helpful
>    for compatibility.

That's up to you. If you want to deprecate in the future, I recommend
you to keep as a patch on your side, so it'll be easier to revert and
less intrusive.


>  * I added some AArch64 for Bitrig in that file, too, to be able to
>    start working on an AArch64 port. As it's still rather early I have
>    not yet tried to send it in.

That's a completely different story. Let's do one ARM architecture at a time.


>  * The Version change is also related to our build system.

Maybe best kept on your side, then.


>  * The second part of the Tools change is, like in Targets, for initial
>    support to compile to AArch64. Same reason as before.
>  * The first part is related to our jump from OABI+soft-float to
>    GNUEABIHF. We needed to pass the ABI and FPU support to GNU as.
>    This particularly code is mostly(?) copied from the Linux part.
>    We probably should get that in, too, but I haven't looked at how to
>    test it.

Same argument, different set of patches.


> The FPU/ABI part reminds me of an issue I encountered today. I have some
> Hypervisor Mode code in the tree, but the integrated assembler complains
> that my CPU does not support the virtualization extentions. Is there a
> way to hard-code Bitrig's default ARM core? Maybe similarly to what
> is being done for FPU/ABI?

A combination of .arch, .arch_extension, .fpu and .cpu should work. I
don't recommend you to hard-code anything, or the system will fail
miserably on non-standard ARM boards (believe me, there are plenty!).
Let the build system define what's needed via build flags.

cheers,
--renato