Keith Walker via llvm-commits llvm-commits at lists.llvm.org
Thu May 26 06:47:40 PDT 2016


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.


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

More information about the llvm-commits mailing list