[PATCH] D14991: [ELF/AArch64] Print a diagnostic message if nonzero addend is used in a GOT relocation.

[Rui Ueyama via llvm-commits]

It sounds like a bit overkill. There are bunch of other cases in which the
linker silently creates broken outputs. As long as creating broken
executables is a natural consequence of providing broken inputs, I wouldn't
try to catch that. My concern is achieving a right balance -- this patch
introduces the concept of "isNonzeroAddendSupported" just for checking some
specific type of error.

On Wed, Nov 25, 2015 at 10:30 AM, Igor Kudrin <ikudrin.dev at gmail.com> wrote:

> ikudrin added a comment.
>
> In http://reviews.llvm.org/D14991#296701, @ruiu wrote:
>
> > Do we really want to have this check? We don't have to check all
> possible ABI violations of input files. This is a kind of ABI violation
> that if you set an addend to a relocation, the output will have a value
> with that addend, which is a natural consequence.
>
>
> As far as I can understand, it's not a violation of ABI rules in input
> files. See section "4.6.3 Relocation types" in
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf
> :
>
> > - GDAT(S+A) represents a 64-bit entry in the GOT for address S+A. The
> entry will be relocated at run time with relocation R_AARCH64_GLOB_DAT(S+A).
>
> > - G(expr) is the address of the GOT entry for the expression expr.
>
>
> And in section "4.6.6 Static AArch64 relocations", "Table 4-14,
> GOT-relative instruction relocations":
>
> > R_AARCH64_ADR_GOT_PAGE: Page(G(GDAT(S+A))) - Page(P)
>
> >  R_AARCH64_LD64_GOT_LO12_NC: G(GDAT(S+A))
>
>
> So, the input is valid, but I'm doubt if it is in use or not. If we don't
> detect the situation we will //silently// produce broken executable file
> with bugs which are very hard to be caught. But if we print a message,
> it'll clearly point to the problem case.
>
>
> http://reviews.llvm.org/D14991
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151125/dd31594e/attachment.html>