This is an archive of the discontinued LLVM Phabricator instance.

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

Authored by ikudrin on Nov 25 2015, 9:41 AM.

Details

Summary

The addend in the GOT relocations for AArch64 has a special meaning,
it requires a separate GOT entry to be created for each S + A case.

It is not clear, if nonzero addends for GOT relocations are used in the wild,
so let's just print a diagnostic message for now.

Diff Detail

Event Timeline

ikudrin updated this revision to Diff 41154.Nov 25 2015, 9:41 AM
ikudrin retitled this revision from to [ELF/AArch64] Print a diagnostic message if nonzero addend is used in a GOT relocation..
ikudrin updated this object.
ikudrin added reviewers: ruiu, rafael, davide.
ikudrin added a project: lld.
ikudrin added a subscriber: llvm-commits.
ruiu edited edge metadata.Nov 25 2015, 9:50 AM

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.

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

ruiu added a subscriber: ruiu.Nov 25 2015, 10:45 AM

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.

davide requested changes to this revision.Nov 25 2015, 10:53 AM
davide edited edge metadata.

I'm personally against the work of catching all ABI violations for reasons fairly similar to the ones already stated by Rui. It adds complexity for very little gain, at least at this phase of development.

This revision now requires changes to proceed.Nov 25 2015, 10:53 AM

It's very weird for me to not detect a known flaw in the product.

ruiu added a comment.Nov 25 2015, 11:09 AM

I'd disagree -- I think it's not a flaw of a product to not detect all
possible corner cases like this.

ruiu added a comment.Nov 25 2015, 11:20 AM

As another data point, we don't check for an object file in an archive file
if the object file really contains a symbol that we found in the archive
file symbol table. Or, for x86-64 TLS relocation optimization, we don't
check for TLS optimization to be used for right combination of
instructions. Because these checks would be too costly for computers or
humans who read code or both.

Your first example violates the expected format of archive, if I understand it right. We may rely on underlying library and its checks in that case.

I have no comment for the second example. May be it's hard to imagine other command or something.

But in this case, I just wanted to detect our own ABI violation. Not to implement that case, as it might be rare, just detect. And I wanted to be honest with our users and not generate broken result from an ABI-compliant input if it can be avoided.

ruiu added a comment.Nov 25 2015, 12:11 PM

They are examples in which we create invalid outputs for broken inputs. My
point still stands. It is not always unacceptable to create invalid outputs
in such case.

Can this be closed?

ikudrin abandoned this revision.Apr 14 2016, 3:52 AM