<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 9, 2018 at 4:52 PM, 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="">Rui Ueyama via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> writes:<br>
<br>
> ruiu added a comment.<br>
><br>
> Isn't it an ABI violation not to write the PLT header for PPC64? If so, we fix that ABI violation rather than "correctly" emitting ABI-violating executables.<br>
<br>
</span>The PPC64 implementation is incomplete. Finishing it would be nice, but<br>
independent of this change.<br>
<br>
Without this change a target must set Target->PltHeaderSize to avoid<br>
having lld confuse the plt and iplt sections, which is not a good design<br>
IMHO.<br></blockquote><div><br></div><div>It is okay to be incomplete, but I'm not very fond of making a change that is not needed for the proper ABI. How about setting a non-zero value to the PPC64 PLT header? We don't have to fill the actual instruction sequence. Setting a non-zero value should fix the issue, right?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>