This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [GOLD] Support --icf=safe with -pie for x86_64

>> Actually, I'd much prefer separate reloc types that just tells the
>> linker whether it's a call or a materialization of a function pointer.
>> In an ideal world, the linker should never have to load section
>> contents until it's applying relocations in pass 2. I really dislike
>> looking at opcodes. Everything we need to know in pass 1 should be
>> available by scanning the relocations.
> I agree completely. The need for this patch (and any related heuristics) comes
> from the fact that the same relocation type is being used for both function
> calls and taking the address of the function. The compiler already knows the
> difference, and an ideal solution would be to simply use different relocation
> types for different use cases.
> What would it take to reach that solution? How involved is it to add a new
> relocation type for something like this? I would guess that some coordination
> is needed with gcc (and other compilers) for this to work. On the binutils
> side, a new relocation type would need support in gas/objdump/ld/gold and maybe
> other places as well. Can you point me to a recent example for adding a similar
> new relocation type so I can get an idea of what it entails?

The x86 psABI is pretty well established, and changing it involves
overcoming a lot of inertia. It's not impossible, though -- there have
been some recent changes, and a few new relocations have been added.
I'd suggest starting with a proposal on the psABI mailing list at If you can recruit enough support, it's
possible that others would contribute the GCC and Gnu ld changes.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]