<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 17, 2017 at 3:11 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">My opinions on this so far are<br>
<br>
There should be just one PT_GNU_RELRO. We should try to get the dynamic<br>
linkers changed only if there is a direct advantaged to having multiple<br>
versus having the static linker putting the data in the right order.<br>
<br>
I am OK with producing an error if a linker script would have caused<br>
mulitple PT_GNU_RELRO to be created.<br></blockquote><div><br></div><div>I'm okay with that too. It doesn't quite right to create a partially-protected binary when we need multiple RELROs. I'd choose one of</div><div><br></div><div> - reporting an error when an output needs more than oen RELRO,</div><div> - emitting a warning that a RELRO segment is not contiguous and don't create RELRO at all, or</div><div> - creating multiple RELROs</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We can probably ignore empty sections when decided the PT_GNU_RELRO<br>
start and end. This means we would have an error only when there is a ro<br>
copy relocation.<br>
<br>
Can we rename the section to .data.rel.ro.bss but keep the current<br>
flags or would bfd error out with bss data not in the end of a PT_LOAD?<br>
<br>
Cheers,<br>
Rafael<br>
<div class="HOEnZb"><div class="h5"><br>
Peter Collingbourne via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> writes:<br>
<br>
> pcc added a comment.<br>
><br>
> In <a href="https://reviews.llvm.org/D40029#927193" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D40029#927193</a>, @peter.smith wrote:<br>
><br>
>> Adding pcc as the original author of <a href="https://reviews.llvm.org/D28272" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D28272</a>.<br>
>><br>
>> Peter, in  <a href="https://reviews.llvm.org/D28272#637284" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D28272#637284</a> you mention that you'd add a follow up patch that used .<a href="http://data.rel.ro" rel="noreferrer" target="_blank">data.rel.ro</a> rather than .<a href="http://bss.rel.ro" rel="noreferrer" target="_blank">bss.rel.ro</a> for the copy relocations. I can't work out if that ever landed. Can you let me know if did? I've just ran into a case where the assumptions made by a ld.bfd linker script cause problems with the .<a href="http://bss.rel.ro" rel="noreferrer" target="_blank">bss.rel.ro</a> name.<br>
><br>
><br>
> No, the use of NOBITS is deliberate. See <a href="http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20170102/417025.html" rel="noreferrer" target="_blank">http://lists.llvm.org/<wbr>pipermail/llvm-commits/Week-<wbr>of-Mon-20170102/417025.html</a><br>
><br>
> Could we instead rename .<a href="http://bss.rel.ro" rel="noreferrer" target="_blank">bss.rel.ro</a> to .<a href="http://data.rel.ro" rel="noreferrer" target="_blank">data.rel.ro</a> only if the linker script has a SECTIONS clause?<br>
><br>
><br>
> <a href="https://reviews.llvm.org/D40029" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D40029</a><br>
</div></div></blockquote></div><br></div></div>