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: [PATCH] Two level comdat priorities in gold

On Mon, Jul 13, 2015 at 4:17 PM, Sriraman Tallam <> wrote:
>     This patch implements a two level comdat function priority.  Comdats defined
> in those objects with a named section ".gnu.comdat.low" are treated with a
> lower priority.  If this patch is suitable, I could add compiler option
> -fcomdat-priority-low which creates this named section in the object file.  For
> testing, I have used the asm directive to create this named section.  Comdat
> priority checking is enabled and honored with new option
> --honor-comdat-priority.
> Context:  I have created this patch to support Module Level Multiversioning.
> Multi versioning at module granularity is done by compiling a subset of modules
> with advanced ISA instructions, supported on later generations of the target
> architecture, via -m<isa> options and invoking the functions defined in these
> modules with explicit checks for the ISA support via builtin functions,
> __builtin_cpu_supports.  This mechanism has the unfortunate side-effect that
> generated COMDAT candidates from these modules can contain these advanced
> instructions and potentially âviolateâ ODR assumptions.  Choosing such a COMDAT
> candidate over a generic one from a different module can cause SIGILL on
> platforms where the advanced ISA is not supported.

There are many different layers of ISAs.  I don't understand how you
can address this problem with two layers of comdats.

You are using a single section to affect all the section groups in the
object file.  I suppose that works if you just want to check command
line options, but what about the __optimize__ attribute, or function
multi-versioning within a single object?

What should happen if people use the -r option to combine several
objects together?

I don't quite understand what problem you are trying to solve.  Is the
problem building programs with advanced ISAs and running them on
machines with older ISAs?  Or is the problem that the linker complains
that functions that it expects to be the same wind up being different
because they are compiled differently?  That is, is there a real
problem, or is there a linker warning problem?


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