<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Mar 23, 2017 10:05 AM, "Rui Ueyama via llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Your .rodata contains a vector of addresses, and we don't know the actual addresses until load-time, because your .so file can be loaded to anywhere in your address space. Thus, we cannot fix .rodata contents at link-time. So your .so needs load-time modifications to the .rodata section. (Does this answer your question?)<br><div><br></div><div>I think our default choice of forbidding relocations against read-only sections is reasonable, because most programs don't need text relocations,</div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">In this case it is rodata though which is a bit more reasonable. If this is really common then we can probably limit our stricter default only to executable sections.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> and if that happens, it is with a high probability a mistake instead of an intentional behavior.</div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Our diagnostic should probably mention to use -z notext though in the case a user needs it. For example, a user might be grateful that we found their bug, but they want to file it in their tracker and get back to it later because their focus at the moment is just to try out LLD on their project (we want them to be able to do that without yak shaving).</div><div dir="auto"><br></div><div dir="auto">It might also be good to distill this discussion into a doc page and have our diagnostic emit a note with a link to it, for users that are less familiar and would benefit from a longer explanation that is too long for a diagnostic. (The rust compiler does something like this for its diagnostics and I found it pretty neat)</div><div dir="auto"><br></div><div dir="auto">-- Sean Silva</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="elided-text"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 23, 2017 at 8:47 AM, Martin Richtarsky via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>Rafael Avila de Espindola wrote:<br>
>> $ gcc -o rodatareloc.s.o -c rodatareloc.s<br>
>> $ lld -o rodatareloc.so -shared rodatareloc.s.o<br>
>><br>
>> ld: error: rodatareloc.s.o:(.rodata+0x0): can't create dynamic<br>
>> relocation<br>
>> R_X86_64_64 against local symbol in readonly segment defined in<br>
>> rodatareloc.s.o<br>
>><br>
>><br>
>> Changing the section from .rodata to .data fixes it, but I guess this<br>
>> should be supported also for .rodata. Should I open a bug?<br>
><br>
> I think this is just a difference in defaults. If you pass "-z notext"<br>
> to lld it should work.<br>
<br>
</span>Thanks, this helps! Any reason why the defaults are different to gold and<br>
presumably bfd-ld?<br>
<br>
I don't understand much of what is happening behind the scenes, but on<br>
loading time, couldn't the rodata section just be mapped read-only, and<br>
still the relocation be applied to the text section, pointing to wherever<br>
rodata was mapped? No modification should be necessary to the rodata<br>
section.<br>
<br>
Thanks and Best regards,<br>
Martin<br>
<div class="m_4216688646548132575m_-7050797736610290542HOEnZb"><div class="m_4216688646548132575m_-7050797736610290542h5">______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div></div>