[PATCH] Delete AArch64II::MO_CONSTPOOL.

[Keith Walker via llvm-commits]

Rafael,

The use of a GOT is not something that is supported for all addressing/linking models;  the "Base Platform ABI for the ARM Architecture" sections 2.4/2.5 mentions some alternative addressing/linking models (that specification is for ARM not AArch64 .... but the concepts are still valid for AArch64).    Obviously testing the change on a platform which is based on a SVr4 linking model which uses a GOT is going to work.

I can confirm that armlink when linking for bare-metal does not allow a GOT as it is not part of the linking model for bare-metal that it supports.

Would the generation of GOT entries work for a Windows style addressing/linking model (if we had an AArch64 Windows)?

I am therefore thinking that the use of MO_CONSTPOOL or GOT should be a selectable option depending on what addressing/linking model you are generating code for (i.e. it is not something special to armlink but rather the addressing/linking model).

Keith

> -----Original Message-----
> From: Rafael Espíndola [mailto:rafael.espindola at gmail.com]
> Sent: 26 May 2016 17:04
> To: Keith Walker
> Cc: Tim Northover; Asiri Rathnayake; llvm-commits; nd
> Subject: Re: [PATCH] Delete AArch64II::MO_CONSTPOOL.
> 
> 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.
> >