<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 19, 2017 at 9:59 AM, Rafael Avila de Espindola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Peter Smith via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> writes:<br>
<br>
> peter.smith created this revision.<br>
> Herald added subscribers: kristof.beyls, javed.absar, aemerson.<br>
><br>
> On many architectures gcc and clang will recognize _GLOBAL_OFFSET_TABLE_ - . and produce a relocation that can be processed without needing to know the value of _GLOBAL_OFFSET_TABLE_. For ARM gcc produces R_ARM_BASE_PREL but clang produces the more general R_ARM_REL32 to _GLOBAL_OFFSET_TABLE_. To evaluate this relocation correctly _GLOBAL_OFFSET_TABLE_ must be defined to be the base of the GOT (R_ARM_BASE_PREL evaluates to this value).<br>
><br>
> If/when llvm-mc is changed to recognize _GLOBAL_OFFSET_TABLE_ - . this change will not be necessary for new objects. However there may still be old objects and versions of clang so I think it is worth making the change in lld as well as fixing llvm-mc.<br>
<br>
</span>I am currently working on fixing the issue in MC.<br>
<br>
This is not part of the documented ABI and I don't think we should do it<br>
unless there is an actual need by an user to keep an old .o file.<br></blockquote><div><br></div><div>I'd agree.I'm conservative on implementing bug-compatibility as it allows buggy programs to produce buggy outputs.</div></div></div></div>