This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] Two level comdat priorities in gold
- From: Ian Lance Taylor <iant at google dot com>
- To: Sriraman Tallam <tmsriram at google dot com>
- Cc: binutils <binutils at sourceware dot org>, Cary Coutant <ccoutant at gmail dot com>, David Li <davidxl at google dot com>, Paul Pluzhnikov <ppluzhnikov at google dot com>, Daniel Berlin <dannyb at google dot com>
- Date: Mon, 20 Jul 2015 11:03:29 -0700
- Subject: Re: [PATCH] Two level comdat priorities in gold
- Authentication-results: sourceware.org; auth=none
- References: <CAAs8HmwHCWKf+Onx=ERLgLpk6276f+jhuW-WiKpvhz6QDxWQ2Q at mail dot gmail dot com>
On Mon, Jul 13, 2015 at 4:17 PM, Sriraman Tallam <firstname.lastname@example.org> 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
> 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
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?