[PATCH] D30256: [ELF] - Implemented -z noreloc-overflow.

George Rimar via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 22 11:08:39 PST 2017


grimar added a comment.

In https://reviews.llvm.org/D30256#683650, @ruiu wrote:

> The fact that the name does not correspond what it does is actually a bit alarming. It could be a sign that something is wrong. Did you know why it was named "noreloc-overflow"?


Yes. I am sorry, now I see that patch was very confusing. They use it for different thing:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/elf64-x86-64.c;h=a058eca3abf03cc2f79601d170b2d6b9f9c459e5;hb=HEAD#l2594
They do not allow to use some relocations as dynamic because they can overflow in runtime
 and report "recompile with fPIC" error instead. To avoid that error, they have this flag.
There is a single relocation in kernel I see that is fixed by that option for them, but we resolve this relocation statically, so at least for my case it was never a problem.

Issue I tried to solve in this patch is different. Issue is that we restrict creating the relocations against RO sections. Though self-relocatable binaries
for kernel wants to have that. For that case I supposed it is fine to ignore all kinds of checks for dynamic relocations under this option. Now I am not sure
that was good idea.

May be we should just allow relocations against text segment when --no-dynamic-linker is given ? That also solves kernel problem and delegates a problem
of handling of such relocation to users generally, what should not be a trouble in that case, because if user specifies no-dynamic-linker, it knows he will
need to handle them anyways. What do you think ?


https://reviews.llvm.org/D30256





More information about the llvm-commits mailing list