Re: clang/llvm on aarch64

[Alan Corey <alan01346%gmail.com@localhost>]

My clang under Linux says:

clang -v
clang version 8.0.1 (tags/RELEASE_801/final)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: /lib/llvm8/bin
Found candidate GCC installation: /usr/lib/gcc/aarch64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/aarch64-linux-gnu/6.3.0
Selected GCC installation: /usr/lib/gcc/aarch64-linux-gnu/6.3.0
Candidate multilib: .;@m64
Selected multilib: .;@m64


On 8/28/19, Michał Górny <mgorny%gentoo.org@localhost> wrote:
> On Wed, 2019-08-28 at 02:40 +0100, Robert Swindells wrote:
>> I wrote:
>> > It looks like clang++ on aarch64 is broken too, but in a different way.
>> >
>> > Static constructors don't get called. I do have a small test
>> > application
>> > that demonstrates this.
>>
>> This looks to be caused by clang/llvm putting the references to the
>> constructor in the .ctors section instead of the .init_array section as
>> required by the ABI.
>>
>> There is code in clang to select this and a web search turns up some
>> patches from 2014 to enable it for all AARCH64 ELF platforms but the
>> source tree seems to have changed a lot since then.
>
> I see the following for Generic_ELF thingy:
>
>   if (DriverArgs.hasFlag(options::OPT_fuse_init_array,
>                          options::OPT_fno_use_init_array,
> UseInitArrayDefault))
>     CC1Args.push_back("-fuse-init-array");
>
> NetBSD should be using that.  Could you verify with 'clang -v' whether
> it's being passed to cc1?
>
>>
>> Does anyone have an account for the llvm bug system to be able to raise
>> this upstream ?
>
> I do and I can do that if we have enough info.  However, submitting
> a patch is always a better option.
>
> --
> Best regards,
> Michał Górny
>
>


-- 
-------------
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach