bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ld: once multiple symbol definitions are allowed, both definitions e


From: Pavel Shishpor
Subject: Re: ld: once multiple symbol definitions are allowed, both definitions end up in the executable
Date: Tue, 17 Jan 2017 15:56:05 +0100

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 <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]