[llvm-dev] [LLD] Can't create dynamic relocation R_X86_64_64 against local symbol in readonly segment

Rui Ueyama via llvm-dev llvm-dev at lists.llvm.org
Thu Mar 23 09:04:49 PDT 2017


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?)

I think our default choice of forbidding relocations against read-only
sections is reasonable, because most programs don't need text relocations,
and if that happens, it is with a high probability a mistake instead of an
intentional behavior.

On Thu, Mar 23, 2017 at 8:47 AM, Martin Richtarsky via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Rafael Avila de Espindola wrote:
> >> $ gcc -o rodatareloc.s.o -c rodatareloc.s
> >> $ lld -o rodatareloc.so -shared rodatareloc.s.o
> >>
> >> ld: error: rodatareloc.s.o:(.rodata+0x0): can't create dynamic
> >> relocation
> >> R_X86_64_64 against local symbol in readonly segment defined in
> >> rodatareloc.s.o
> >>
> >>
> >> Changing the section from .rodata to .data fixes it, but I guess this
> >> should be supported also for .rodata. Should I open a bug?
> >
> > I think this is just a difference in defaults. If you pass "-z notext"
> > to lld it should work.
>
> Thanks, this helps! Any reason why the defaults are different to gold and
> presumably bfd-ld?
>
> I don't understand much of what is happening behind the scenes, but on
> loading time, couldn't the rodata section just be mapped read-only, and
> still the relocation be applied to the text section, pointing to wherever
> rodata was mapped? No modification should be necessary to the rodata
> section.
>
> Thanks and Best regards,
> Martin
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170323/517dc893/attachment.html>


More information about the llvm-dev mailing list