Thanks a lot for the answer: it put me on the right track. The
'-ffunction-sections' option works OK on toy examples though GNU linker
crashed when I tried the following on real-life object files compiled with
-ffunction-sections and -fdata-sections options enabled:
for i in $object_files_original
do
objcopy --weaken $i # weaken symbols for linker not to complain
about multiple definitions
done
ld.bfd -r --gc-sections -u external_symbol1...
$object_files_with_replacement_fucntions
$object_files_original -o combined.o
ld.bfd: BFD (GNU Binutils) 2.27 assertion fail elflink.c:8380
<repeated 6 times more>
Any clues how to debug it?
Also I have not tried COMDAT magic: looks like there are no any external
tweaks to put function to COMDAT sections but g++ decides on its own what
should be go to COMDAT sections.
On Wed, Jan 11, 2017 at 8:50 PM, Jim Wilson <[email protected]> wrote:
> On 01/11/2017 01:49 AM, Pavel Shishpor wrote:
>
>> Could please someone advice is it a bug or a feature when we get both
>> bodies of the functions with the same name in the executable once
>> multiple symbol definitions are allowed? Here is the example showing the
>> behavior:
>>
>
> The only thing that the --allow-multiple-definitions option does is
> disable the error message that you would normally get. It doesn't change
> how the linker output is created. So yes, you will end up with both
> definitions in the output.
>
> It is best to avoid getting multiple definitions in the first place.
>
> If you want the linker to discard unused functions, then each function
> must be in its own section via gcc -ffunction-sections and then use the
> linker --gc-sections option. However, this may cause problems of its own,
> e.g. debug functions may disappear because they appear unused, it won't
> work for libraries where most functions are meant to be used by an
> application it is linked with, etc. Or alternatively, you can try making
> it a COMDAT function, then duplicates get dropped automatically.
>
> For your example, the duplicate f function is in the same text section as
> the main function, which can't be deleted. The assembler may resolve
> intra-section references itself. Which means editing the text section to
> remove the f function may break other things in the same section, which is
> unsafe, and hence the linker can't do it. Thus the requirement that we can
> only delete functions that are in their own section.
>
> Jim
>
>
_______________________________________________
bug-binutils mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-binutils
