GCC __symver__ attribute support #459
Comments
|
Ok, I patched Patch for sys-cluster/glusterfs-6.5: --- a/api/src/glfs-internal.h
+++ b/api/src/glfs-internal.h
@@ -81,16 +81,16 @@
#define GFAPI_PRIVATE(sym, ver) /**/
#endif
#define GFAPI_SYMVER_PUBLIC_DEFAULT(fn, ver) \
- asm(".symver pub_" STR(fn) ", " STR(fn) "@@GFAPI_" STR(ver))
+ extern __typeof (pub_##fn) pub_##fn __attribute__((symver (STR(fn) "@@GFAPI_" STR(ver))))
#define GFAPI_SYMVER_PRIVATE_DEFAULT(fn, ver) \
- asm(".symver priv_" STR(fn) ", " STR(fn) "@@GFAPI_PRIVATE_" STR(ver))
+ extern __typeof (priv_##fn) priv_##fn __attribute__((symver (STR(fn) "@@GFAPI_PRIVATE_" STR(ver))))
#define GFAPI_SYMVER_PUBLIC(fn1, fn2, ver) \
- asm(".symver pub_" STR(fn1) ", " STR(fn2) "@GFAPI_" STR(ver))
+ extern __typeof (pub_##fn1) pub_##fn1 __attribute__((symver (STR(fn2) "@GFAPI_" STR(ver))))
#define GFAPI_SYMVER_PRIVATE(fn1, fn2, ver) \
- asm(".symver priv_" STR(fn1) ", " STR(fn2) "@GFAPI_PRIVATE_" STR(ver))
+ extern __typeof (priv_##fn1) priv_##fn1 __attribute__((symver (STR(fn2) "@GFAPI_PRIVATE_" STR(ver))))
#define STR(str) #str
#else
#ifndef GFAPI_PUBLIC |
|
Found an suspect in my overrides: media-libs/alsa-lib-1.2.1.2 --- a/include/alsa-symbols.h
+++ b/include/alsa-symbols.h
@@ -30,9 +30,9 @@
#define INTERNAL(Name) INTERNAL_CONCAT2_2(__, Name)
#define symbol_version(real, name, version) \
- __asm__ (".symver " ASM_NAME(#real) "," ASM_NAME(#name) "@" #version)
+ extern __typeof (real) real __attribute__((symver (#name "@" #version)))
#define default_symbol_version(real, name, version) \
- __asm__ (".symver " ASM_NAME(#real) "," ASM_NAME(#name) "@@" #version)
+ extern __typeof (real) real __attribute__((symver (#name "@@" #version)))
#define EXPORT_SYMBOL __attribute__((visibility("default"),externally_visible))
Compiled fine with -flto enabled. Looks like everything works as before so far. I guess we should kindly ask Gentoo™ to backport those GCC patches, so we will be able to play w/ symver more freely. Anyone with account on bugs.gentoo.org ? |
|
Do we know when gcc-10 will be released? If it's not too long (their release timeline if they've stuck to it seems to suggest it won't be much longer), rather than backporting patches it could be more beneficial to import a newer snapshot of gcc to this overlay for testing. |
|
Near 2020-05 according to release timeline? Then 10.1 will be masked for a while in portage. My attempt to port them for gcc-9.2.0: |
|
We should really look into this for when GCC 10 comes around. It could knock off a chunk of overrides |
|
Hm... Are there any GCC 10 live ebuilds in the Gentoo tree? If so, how smart would it be to switch to the compiler on a day-to-day system? |
|
@elsandosgrande |
|
|
@pchome So... I see no keywords for GCC 10... |
|
I mean Also use |
|
Since this is an unstable package you also have to promise not to bug the Gentoo toolchain maintainers (do not file bugs on bugs.gentoo.org): /etc/portage/env/i-promise-to-supply-patches-with-bugs/etc/portage/package.env(that can also be a folder in which case use something like I wouldn't use this on your host system, maybe in a chroot though. |
|
|
BTW, ... EDIT: a live example how to use this: There is a patch and it compiles with LTO. It has some interesting parts:
-int libattr_lsetxattr(const char *path, const char *name,
- void *value, size_t size, int flags)
+__attribute__((no_reorder))
+int lsetxattr(const char *path, const char *name,
+ const void *value, size_t size, int flags)
{
return syscall(__NR_lsetxattr, path, name, value, size, flags);
}
+__asm__(".symver lsetxattr, lsetxattr@ATTR_1.0");The GCC 10 specific changes could look like this: +__attribute__((__symver__ ("lsetxattr@ATTR_1.0")))
int libattr_lsetxattr(const char *path, const char *name,
const void *value, size_t size, int flags)Which compiles and passes symbol test too. |
Gcc10 introduced different strategy how to build shared libraries with their new LTO optimizer. Insired by: https://akkadia.org/drepper/symbol-versioning https://sourceware.org/pipermail/elfutils-devel/attachments/20200414/1c0c2903/attachment.bin InBetweenNames/gentooLTO#459 https://github.com/linux-rdma/rdma-core/blob/master/util/symver.h https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
It looks like future versions of GCC (>=10.0 ?) will introduce
__symver__attribute as possible replacement for theasm (".symver foo_v1, foo@VERS_1")code. Which will likely help some packages to compile with -flto (#458 ?).Description
Note: I manually converted formatting to MD, so there might be errors, especially with @
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
externally referenced. The
nodenameportion should be the name of anode specified in the version script supplied to the linker when building a
shared library. Versioned symbol must be defined and must be exported with
default visibility.
Will produce a
.symver foo_v1, foo@VERS_1directive in the assembleroutput.
It's an error to define multiple version of a given symbol. In such case
an alias can be used.
This example creates an alias of
foo_v1with symbol namesymver_foo_v1which will be versionVERS_2offoo.Finally if the parameter is
"name2@@nodename"then inaddition to creating a symbol version (as if
"name2@nodename"was used) the version will be also usedto resolve name2 by the linker.
Discussions
https://gcc.gnu.org/ml/gcc-patches/2019-11/threads.html#01334
https://gcc.gnu.org/ml/gcc-patches/2019-12/threads.html#00032
https://gcc.gnu.org/ml/gcc-patches/2019-12/threads.html#01162
Patches
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02712.html - symver attribute support
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01363.html - some binutils workarounds
Possible conversion
before
after
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00040.html
The text was updated successfully, but these errors were encountered: