[PATCH] Make Bitrig/ARM use Itanium-ABI

[Patrick Wildt]

Hi Renato,

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.

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.

I have a few more bits for libc++, libc++abi and even compiler-rt that I
need so clean, sort out and send in, too.

I can give you a "short" rundown of what the individual parts to and
what we probably should get in somehow:

 * The Host.inc change is for compatibility with how we build LLVM in
   our tree. This is not relevant for upstream.
 * 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...
 * ARMMCAsmInfo change was send in today.
 * I don't know what the Options.td check is for, I need to understand
   that.
 * 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.
 * 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.
 * The Version change is also related to our build system.
 * 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.

I hope this explains the reasons for those patches well. Let me know if
you have any questions. What parts do you think are good to go in (with
a proper test)?

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?

Thanks for the hints. Next time I'll be trying to make it easier for
you. I will have a look at Phabricator. :)

Sorry for the wall of text.

Best regards,
Patrick

[0]
https://github.com/bitrig/bitrig/commit/6368241593c895592929cde947507eab071ecc87

On Thu, Feb 19, 2015 at 06:41:46PM +0000, Renato Golin wrote:
> Hi Patrick,
> 
> Do you have any more Bitrig patches? I think they're all very related
> and could be bundled in one patch.
> 
> Also, it's better if you attach your patches, rather than leave them
> in the body (it's easier to download and apply). And if you have
> multiple patches, also please send them in sequence from the same git
> branch, so that it's easier to apply.
> 
> Finally, if you could use Phabricator
> (http://reviews.llvm.org/differential/), it'd be easier to review,
> download, apply and discuss the patches.
> 
> cheers,
> --renato
>