[PATCH] Make Bitrig/ARM use Itanium-ABI

[Patrick Wildt]

> Am 19.02.2015 um 22:24 schrieb Renato Golin <renato.golin at linaro.org>:
> 
> 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.

When you say components, do you mean only LLVM/clang, or also
libc++(abi) and compiler-rt?

But I guess the „one patch per component“ should be focused on
a specific topic? Like… Only ARM ABI, but not x86 for instance?

Sorry, I might not be following completely.

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

That is correct. This link was only to show our diff. I have the git
repositories cloned to my local machines. The diffs I sent out were
based on those.

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

I will take care. My plan for now is to get what we have so far into master,
once LLVM 3.6.0 is out, and make sure to have it stable and get snapshots
out of the door. I’ll make sure to take care of that ASAP.

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

I was just talking to someone about it. Apparently OpenBSD’s prof
became gprof at some point, so -p became a synonym for -pg.

We can probably change our code to use -pg at Bitrig, which would
make this diff obsolete.

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

Ok, good.

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

Well, not entirely. The first part of that change is for the ARM architecture,
not AArch64. The second part of the change in that file is for AArch64.

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

I totally believe you there. We currently target only a specific set of
machines. ARMv7, VFPv3. That is a must. Even though it might sound
weird, we’re basically doing „one kernel to rule them all“. So far I can run
the same kernel on all my boards (apart from the u-boot umg header for
the physical load address).

Best regards,
Patrick