From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 9309C388A007; Thu,  2 Apr 2020 11:14:06 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9309C388A007
From: "mark at klomp dot org" <sourceware-bugzilla@sourceware.org>
To: elfutils-devel@sourceware.org
Subject: [Bug general/24498] 0.176: isn't LTO ready
Date: Thu, 02 Apr 2020 11:14:06 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: elfutils
X-Bugzilla-Component: general
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mark at klomp dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-24498-10460-hrlaXvZhgE@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-24498-10460@http.sourceware.org/bugzilla/>
References: <bug-24498-10460@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: elfutils-devel@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Elfutils-devel mailing list <elfutils-devel.sourceware.org>
List-Unsubscribe: <http://sourceware.org/mailman/options/elfutils-devel>,
 <mailto:elfutils-devel-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/elfutils-devel/>
List-Help: <mailto:elfutils-devel-request@sourceware.org?subject=help>
List-Subscribe: <http://sourceware.org/mailman/listinfo/elfutils-devel>,
 <mailto:elfutils-devel-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Apr 2020 11:14:06 -0000

https://sourceware.org/bugzilla/show_bug.cgi?id=3D24498

--- Comment #7 from Mark Wielaard <mark at klomp dot org> ---
We need a way to generate symbol versions without having to use (top-level)
inline assembly. It appears GCC 10 will provide this:
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html

We should try to use this to define the symbol version macros (OLD_VERSION,
NEW_VERSION, COMPAT_VERSION_NEWPROTO, COMPAT_VERSION) in lib/eu-config.h

symver ("name2@nodename")

    On ELF targets this attribute creates a symbol version. The name2 part =
of
the parameter is the actual name of the symbol by which it will be external=
ly
referenced. The nodename portion should be the name of a node specified in =
the
version script supplied to the linker when building a shared library. Versi=
oned
symbol must be defined and must be exported with default visibility.

    __attribute__ ((__symver__ ("foo@VERS_1"))) int
    foo_v1 (void)
    {
    }

    Will produce a .symver foo_v1, foo@VERS_1 directive in the assembler
output.

    It=E2=80=99s an error to define multiple version of a given symbol. In =
such case an
alias can be used.

    __attribute__ ((__symver__ ("foo@VERS_2")))
    __attribute__ ((alias ("foo_v1")))
    int symver_foo_v1 (void);

    This example creates an alias of foo_v1 with symbol name symver_foo_v1
which will be version VERS_2 of foo.

    Finally if the parameter is "name2@@nodename" then in addition to creat=
ing
a symbol version (as if "name2@nodename" was used) the version will be also
used to resolve name2 by the linker.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=