[PATCH] Make Bitrig/ARM use Itanium-ABI

[Patrick Wildt]

Whoops, typo down below.

> Am 19.02.2015 um 20:50 schrieb Patrick Wildt <mail at patrick-wildt.de>:
> 
> 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

*no definite (of course)

>   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
>>