<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 10, 2018 at 9:01 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"><div class="HOEnZb"><div class="h5">Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> writes:<br>
<br>
> On Tue, Jan 9, 2018 at 5:47 PM, Rafael Avila de Espindola <<br>
> <a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
><br>
>> Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> writes:<br>
>><br>
>> > On Tue, Jan 9, 2018 at 4:52 PM, Rafael Avila de Espindola <<br>
>> > <a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
>> ><br>
>> >> 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<br>
>> so,<br>
>> >> we fix that ABI violation rather than "correctly" emitting ABI-violating<br>
>> >> executables.<br>
>> >><br>
>> >> 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>
>> >><br>
>> ><br>
>> > It is okay to be incomplete, but I'm not very fond of making a change<br>
>> that<br>
>> > is not needed for the proper ABI. How about setting a non-zero value to<br>
>> the<br>
>> > PPC64 PLT header? We don't have to fill the actual instruction sequence.<br>
>> > Setting a non-zero value should fix the issue, right?<br>
>><br>
>> I think the way to look at this patch is a cleanup, not a fix.<br>
>><br>
>> I find<br>
>><br>
>>   if (IsIplt) {<br>
>><br>
>> A lot easier to read than<br>
>><br>
>>   if (HeaderSize == 0) {<br>
>><br>
>> I does happen to fix a problem with the ppc64 target, but that is almost<br>
>> incidental. And yes, it could be made a pure cleanup by setting the<br>
>> ppc64 PltHeaderSize to a nonzero value first.<br>
>><br>
><br>
> Sure. But if PLTs for all targets have the PLT header for lazy symbol<br>
> resolution (I believe that's the case), and IPLT doesn't have one (I<br>
> believe that's true too), then we can use `bool is Iplt() { return<br>
> HeaderSize == 0; }` instead of adding a new boolean flag to the ctor.<br>
<br>
</div></div>But that is a coincidence that happens to be true is most targets, no?<br></blockquote><div><br></div><div>I don't think that's a coincidence. If you implement lazy resolution, it is a natural consequence to have a PLT header. It can be PLT trailer or can reside in other section, I doubt if such ABI exists.</div><div><br></div><div>Even if we consider this patch as a cleanup, this patch is incomplete. I'll send follow-up comments.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Why are all targets required to have a plt header? Some as George point<br>
out don't even have a plt, let alone lazy resolution.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>