<div dir="ltr">The failure mode for treating -R as --rpath when the user wanted --just-symbols is arcane and confusing, but it is not silent.  So I don't think there's great risk in leaving -R as it is.<div>Personally, I think it would be fine for -R to just be an error telling you to pick --rpath or --just-symbols instead.  A conservative alternative would be to make it a warning, but continue treating it as --rpath.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 30, 2017 at 12:44 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>A chance to write a new general-purpose linker from scratch happens only once in a decade or so, and my wish is to not carry over old hairy command line options whenever possible. As a practical linker, we sometimes have to implement hairy features, but that doesn't mean we want to copy everything. I do not see a strong feature request from many people to copy the GNU's -R option yet. Once you add the feature, it is irreversible. I think you shouldn't copy the feature at least now.</div><div><br></div><div>Dropping the -R option is tempting, but since we had this option as an alias to -rpath in the older releases in lld, we should be conservative. I don't think it is a good idea to change the existing behavior without a strong reason. I'm not so sure that -R is not in use in the wild.</div><div><br></div><div>Also, can you please do not implement a feature without discussing whether we want it or not in the first place? "Because we already have a patch and it's simple" shouldn't be a reason to add a new feature when something else matters more than that.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 30, 2017 at 12:49 AM, George Rimar <span dir="ltr"><<a href="mailto:grimar@accesssoftek.com" target="_blank">grimar@accesssoftek.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir="ltr" style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<p>I think I agree that we should not make assumptions on runtime <span style="color:rgb(33,33,33);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:16px;background-color:rgb(255,255,255)">
environment </span>(so I would not touch current -rpath behavior).<br>
</p>
<p>Though my position here is based on safety mostly. It is definetely safe to leave current behavior which is consistent with GNU linkers<br>
</p>
<p>and is very simple (as does not require checking anything).<br>
</p>
<p><br>
</p>
<p>About -R I really do not know is it common or not (I thought not because we have no testcases for -R), </p>
<p>but assuming it is common and taking the fact it shares behavior<br>
</p>
<p>and LLD produces broken output silently, what about emiting warning like:<br>
</p>
<p>"-R (-rpath): option is depricated/unsupported. Consider using <span style="color:rgb(33,33,33);font-family:Calibri,Arial,Helvetica,sans-serif;font-size:16px;background-color:rgb(255,255,255)"> -rpath or-just-symbols</span> instead."<br>
</p>
<p>if -R was used ?<br>
</p>
<p><br>
</p>
<p><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:16px;background-color:rgb(255,255,255)">We are in good position to change behavior of badly designed things probably.</span> And can do that in a hard or <span style="font-size:12pt">s</span><span style="font-size:12pt">oft
 way,</span></p>
<p><span style="font-size:12pt">warning is probably soft safe way. </span><span style="font-size:12pt">(And </span><span style="font-size:12pt">I believe it</span><span style="font-size:12pt"> -R</span><span style="font-size:12pt"> can be leaved as
 alias with this approach</span><span style="font-size:12pt">).</span></p>
<p><br>
</p>
<div id="m_4834972612088599498m_-3346783187775929809Signature">
<div name="divtagdefaultwrapper">
<div class="m_4834972612088599498m_-3346783187775929809BodyFragment"><font size="2">
<div class="m_4834972612088599498m_-3346783187775929809PlainText">Best regards,<br>
George | Developer | <span style="background-color:rgb(255,255,255);color:rgb(33,33,33);font-family:Calibri,sans-serif;font-size:13.3333px">Access Softek, Inc</span></div>
</font></div>
</div>
</div>
<div style="color:rgb(33,33,33)">
<hr style="display:inline-block;width:98%">
<div id="m_4834972612088599498m_-3346783187775929809divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>От:</b> Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>><br>
<b>Отправлено:</b> 30 ноября 2017 г. 4:30<br>
<b>Кому:</b> Rafael Avila de Espindola<br>
<b>Копия:</b> George Rimar; <a href="mailto:reviews%2BD40558%2Bpublic%2Beb8f52c2c2ffee2b@reviews.llvm.org" target="_blank">reviews+D40558+public+eb8f52c2<wbr>c2ffee2b@reviews.llvm.org</a>; Roland McGrath; Evgeny Leviant; llvm-commits; Ed Maste<br>
<b>Тема:</b> Re: [PATCH] D40558: [ELF] - Trigger error when -R <filename> is given.</font>
<div> </div>
</div><div><div class="m_4834972612088599498h5">
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Wed, Nov 29, 2017 at 8: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>George Rimar <<a href="mailto:grimar@accesssoftek.com" target="_blank">grimar@accesssoftek.com</a>> writes:<br>
<br>
>>I think we shouldn't even emit an error for the second case. -rpath is the information for the dynamic linker, and the static linker should blindly store given -rpath >paths to a file header, because the static linker doesn't know the actual runtime environment.
 It is a valid use case that a given -rpath is not a directory in a build >environment but a directory in a runtime environment.<br>
>><br>
>>Given that, I'm inclined to not to emit an error or a warning at all for -R and just make it an alias to -rpath. If you are so familiar with linker features that you want to >use --just-symbols, you are likely to know -R, -rpath and -just-symbols. -just-symbols
 is used very rarely, so in reality, I think this is not an issue.<br>
><br>
> Two points from me:<br>
> "Given that, I'm inclined to not to emit an error or a warning at all for -R and just make it an alias to -rpath. If you are so familiar with linker features that you want to use --just-symbols, you are likely to know -R"<br>
><br>
> Last part means that we should implement -R both for -rpath and --just-symbols, like original GNU linkers do. As it is what is expected by user, who familar with both.<br>
> Currently our behavior always behaves as -rpath without warnings or errors and produce broken output. And that nehavior is definetely not expected (and comments for PR35067 shows that).<br>
><br>
> And then making -R an alias for one of these options is just not correct. If it's intention is to share 2 different behaviors it should be separate option with corresponding description, no ?<br>
><br>
</span>> ?Currently no our tests use -R for -rpath. What about if we drop supporting -R completely ? We can show a error suggesting to use explicitly use -rpath/--just-symbols instead.<br>
<br>
I *think* that using -R for --rpath is fairly common.<br>
<br>
I think I am back to favoring -R being an alias for rpath and producing<br>
an error for "--rpath file" or "-R file". Yes, the build machine might<br>
have a file and the intended run environment a directory, but that seems<br>
unlikely and easy to avoid.<br>
</blockquote>
<div><br>
</div>
<div>I'm not in favor of that. Reasons being that (1) assuming that a runtime environment is the same as a build environment is generally a bad idea even though it can be easily avoided, (2) --just-symbols is used very rarely, and (3) the -R option's behavior
 is undeniably a bit too hacky. Now seems like a good time to kill that tricky behavior.</div>
</div>
</div>
</div>
</div>
</div></div></div>
</div>

</blockquote></div><br></div>
</div></div></blockquote></div><br></div>