This is the mail archive of the
mailing list for the binutils project.
Re: [GOLD] Support --icf=safe with -pie for x86_64
- From: Cary Coutant <ccoutant at gmail dot com>
- To: Rahul Chaudhry <rahulchaudhry at google dot com>
- Cc: Alan Modra <amodra at gmail dot com>, Binutils <binutils at sourceware dot org>, Sriraman Tallam <tmsriram at google dot com>
- Date: Fri, 20 Jan 2017 18:00:07 -0800
- Subject: Re: [GOLD] Support --icf=safe with -pie for x86_64
- Authentication-results: sourceware.org; auth=none
- References: <CAJRD=oqcd2y03pjosB6ifygwGv1wO0VgPFFqvTiSOvFhaqisJA@mail.gmail.com> <20170113012324.GO32333@bubble.grove.modra.org> <CAJRD=opJc+d+RENAfdndtyB2mjSHLTgXfhua2KF=R46dtkA-4Q@mail.gmail.com> <CAJimCsE=L3ZqLCxSn=V_HA_+BWL3uwjp5uoPtuQjk1sEXX1bhg@mail.gmail.com> <CAJRD=oq+MyiTzpLjWHTCG5Oz57zjBCmLQUHEptdK3pJNhb0Lyg@mail.gmail.com>
>> 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
firstname.lastname@example.org. If you can recruit enough support, it's
possible that others would contribute the GCC and Gnu ld changes.