[PATCH] Delete AArch64II::MO_CONSTPOOL.

[Rafael Espíndola via llvm-commits]

It seems far more reasonable to expect the linker to be able to create
a got entry. It has the code already for when creating shared
libraries, it can create a got entry too when producing an executable.

I just tested that I can bootstrap on aarch64 with my patch on linux.
To make sure it is handling this, I included a

__attribute__((weak)) extern int foobarzed;

and added a

assert(&foobarzed == (int*)0);

to SmallVectorBase::grow_pod. And the assert never fires, so the
linker created a got entry and it correctly contains 0.

If armlink is really incapable of creating a got entry when producing
an executable, we should document that MO_CONSTPOOL exist just to work
around that limitation. Ideally we would not use MO_CONSTPOOL when not
using armlink so as to not penalize other ELF and MachO linkers.

Could you please check that armlink still has this restriction?

Cheers,
Rafael



On 26 May 2016 at 09:47, Keith Walker <Keith.Walker at arm.com> wrote:
> Tim/Rafael,
>
> The motivation for the original change is that when compiling for the bare-metal environment you do not usually have a GOT, and as you surmised Tim we encountered the problem when armlink reported an error when linking non-PIC code.
>
> Compiling this contrived example for static linking (i.e. not PIC) ....
>
> extern __attribute__((weak)) int x;
> extern int y;
> int fn()
> {
>         return x + y;
> }
>
> The original patch (currently applied to LLVM) made the aarch64 code similar to the arm code in that no GOT entry is generated for x in this case.
>
> When I compile the above with gcc it appears to be compiling the above code with no GOT relocations either.
>
> Obviously with the reversion of this patch a GOT entry would be generated for x on aarch64.
>
> So the question is whose job is it to resolve the GOT issue in this case .... should the compiler not generate GOT entries in the 1st place when compiling statically (e.g. for bare-metal), or is it the responsibility of the linker to do something to handle the GOT relocations when linking for bare-metal .... Hmmmm!
>
> You can probably guess from my patch which solution I chose.
>
> Keith
>
>> -----Original Message-----
>> From: Tim Northover [mailto:t.p.northover at gmail.com]
>> Sent: 26 May 2016 00:08
>> To: Rafael Espíndola; Asiri Rathnayake; Keith Walker
>> Cc: Tim Northover; llvm-commits
>> Subject: Re: [PATCH] Delete AArch64II::MO_CONSTPOOL.
>>
>> On 25 May 2016 at 15:31, Rafael Espíndola <llvm-commits at lists.llvm.org>
>> wrote:
>> > It produces exactly the same instruction sequence as a got use and
>> > unlike a got use this is not uniqued by the linker.
>> >
>> > I will try bootstrapping this, but sending for review now in case
>> > someone remembers the reason for adding it.
>>
>> I've added Asiri and Keith explicitly, since I think they were behind
>> the original patch (r217503) and have access to ARM bugtrackers which
>> may have more information.
>>
>> It looks like both GNU linkers are capable of adding a GOT when
>> linking statically, was it a limitation in armlink or something?
>>
>> Tim.
>