<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, May 9, 2017 at 1:56 PM Rafael Avila de Espindola <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Add an extra walk, but only if we know the link will fail. I *think*<br>
  this was what the previous patch did. IMHO so far this is the best<br>
  option.<br></blockquote><div><br></div><div>That's the one I implemented initially.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Report this particular undefined symbol with less information. I would<br>
  save this as an easy last resort.<br></blockquote><div><br></div><div>I considered this option, it'd be easy to implement but it's undesirable.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Always define the symbol.<br></blockquote><div><br></div><div>I'm fine implementing this as an initial solution.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Report undefined symbols in InputSection::relocateNonAlloc and<br>
  InputSectionBase::relocate instead of the current location (requires a<br>
  benchmark).<br></blockquote><div><br></div><div>I considered this but haven't implemented it as it's a bigger change. I can give it a try to see what would be the impact.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Remember more information during the first scan, that seems the least<br>
  desirable.<br></blockquote><div><br></div><div>That's the current implementation.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Figure out earlier if we are going to allocate the headers. This is<br>
  hard and just a conservative heuristic. For example, it is possible to<br>
  construct a case where a PT_GNU_RELRO is not needed, but we don't know<br>
  that until we known that a .got is not needed.<br></blockquote><div><br></div><div>I tried this one, but it felt too complicated, there was a lot of duplication of code and I always managed to come up with a counter-example where it didn't work.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We already use the strategy of tentatively creating things and deleting<br>
them if we find out we don't need them, so if we can make that work in<br>
here that would be my preference.</blockquote><div><br></div><div>IIUC this would work if we move the reporting to InputSection::relocateNonAlloc and InputSectionBase::relocate; we can define __ehdr_start unconditionally and later change it to undefined symbol if we find out it's needed.</div></div></div>