This is the mail archive of the binutils@sourceware.org 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: [PATCH] Two level comdat priorities in gold


On Mon, Jul 20, 2015 at 12:32 PM, Xinliang David Li <davidxl@google.com> wrote:
>
> If a user uses __optimize__ attribute on a function to enable an ISA
> extension, but does not guard the call of the function with ISA
> feature testing, it is considered a user error. We only need to
> improve the tool chain here to help users where he does not have any
> other control -- basically when a common library function defined in
> the header gets implicitly versioned due to the use of -mxxx option.
> In other words, currently for C++ programs, using -mxxx on a module is
> basically broken, and this patch tries to address that.

So the problem is that an object file compiled with -mxxx may include
definitions of non-inlined functions and instantiated templates with
vague linkage that are compiled with -mxxx.  At link time, these same
functions/templates may appear in object files not compiled with
-mxxx.  When the linker happens to resolve the vague linkage by
selecting the -mxxx instantiations, the calls from the non-mxxx
objects are erroneous.

The proposal is to compile the -mxxx versions with a special compiler
option that causes the definitions with vague linkage in that object
to only be used if they are the only definition.  The idea is that the
user will use the special compiler option whenever using -mxxx options
that are incompatible with the baseline build.

One minor disadvantage is that -mxxx code will not reliably call -mxxx
template functions, even when such functions would be better
optimized.


>> What should happen if people use the -r option to combine several
>> objects together?
>
> Can the linker pick the higher prirority comdat?

Sure, but the proposed representation is to add a special section that
affects the interpretation of the entire object.  How should that
special section by handled when using -r with a combination of some
objects that have the section and some do not?



While it is possible to construct test cases for this problem using C
inline functions, in practice the problem is going to arise in C++.
In C++ it's similar to the problem solved by using ABI tags.  This
suggests to me that we should have a compiler option allowing an ABI
tag to be specified for all weak definitions.  As far as I can see
that would address the entire problem, with no confusion about -r, and
permitting optimized functions to call optimized versions of the vague
linkage definitions.

Ian


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