Re: [PATCH] docs: update symver attribute description

On 4/12/21 3:50 PM, H.J. Lu wrote: > GCC failed to bootstrap: > > /export/gnu/import/git/sources/gcc/gcc/doc/extend.texi:3870: misplaced { > /export/gnu/import/git/sources/gcc/gcc/doc/extend.texi:3872: misplaced } > /export/gnu/import/git/sources/gcc/gcc/doc/extend.texi:3874: unknown > command `VE

Re: [PATCH] docs: update symver attribute description

On Mon, Apr 12, 2021 at 5:54 AM Martin Liška wrote: > > On 4/12/21 2:18 PM, Jakub Jelinek wrote: > > On Mon, Apr 12, 2021 at 02:15:16PM +0200, Martin Liška wrote: > >> The old syntax with the alias is quite ugly.. > > > > Not that much. And users have no other option (besides inline asm > > but t

Re: [PATCH] docs: update symver attribute description

point! Is it fine now? Ok, thanks. > >From 6dda0ec10a1b0c60e6e9afe7fc45370d0132b5e3 Mon Sep 17 00:00:00 2001 > From: Martin Liska > Date: Mon, 12 Apr 2021 13:42:33 +0200 > Subject: [PATCH] docs: update symver attribute description > > gcc/ChangeLog: > > * doc/extend.t

Re: [PATCH] docs: update symver attribute description

fuse users. For symbol versions which just a single symbol they > don't need any aliases... Very good point! Is it fine now? Thanks, Martin > > Jakub > >From 6dda0ec10a1b0c60e6e9afe7fc45370d0132b5e3 Mon Sep 17 00:00:00 2001 From: Martin Liska Date: Mon, 12 Apr 2021 13:4

Re: [PATCH] docs: update symver attribute description

On Mon, Apr 12, 2021 at 02:32:35PM +0200, Martin Liška wrote: > +If you have an older release of binutils release, then symbol alias needs to s/binutils release/binutils/ > +be used: > + > +@smallexample > +__attribute__ ((__symver__ ("foo@@VERS_2"))) > +__attribute__ ((alias ("foo_v1"))) > +int

Re: [PATCH] docs: update symver attribute description

ight, so something like this? Thanks, Martin >From 750b715225d480fcb74e765623d54acc42ac25e3 Mon Sep 17 00:00:00 2001 From: Martin Liska Date: Mon, 12 Apr 2021 13:42:33 +0200 Subject: [PATCH] docs: update symver attribute description gcc/ChangeLog: * doc/extend.texi: Be more precise in docu

Re: [PATCH] docs: update symver attribute description

On Mon, Apr 12, 2021 at 02:15:16PM +0200, Martin Liška wrote: > The old syntax with the alias is quite ugly.. Not that much. And users have no other option (besides inline asm but that doesn't work with LTO well). > > so that people who don't have gcc configured against > > binutils 2.35 or newe

Re: [PATCH] docs: update symver attribute description

/extend.texi: Be more precise in documentation >> of symver attribute. > > Ok, but I'd prefer to see the old example with the old description in the > documentation too The old syntax with the alias is quite ugly.. > so that people who don't have gcc configured

Re: [PATCH] docs: update symver attribute description

On Mon, Apr 12, 2021 at 01:44:54PM +0200, Martin Liška wrote: > This improves documentation as noticed by Jakub. > > Ready for master? > Thanks, > Martin > > gcc/ChangeLog: > > * doc/extend.texi: Be more precise in documentation > of symver attribute.

[PATCH] docs: update symver attribute description

This improves documentation as noticed by Jakub. Ready for master? Thanks, Martin gcc/ChangeLog: * doc/extend.texi: Be more precise in documentation of symver attribute. --- gcc/doc/extend.texi | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/gcc/doc

doc: Fix up symver attribute documentation

what each of them does and mention that only binutils 2.35 and later actually handle some of the forms. 2021-04-01 Jakub Jelinek * doc/extend.texi (symver attribute): Fix up syntax errors in the examples. --- gcc/doc/extend.texi.jj 2021-03-03 09:43:57.898723872 +0100 ++

Re: [PATCH] doc: Add @cindex to symver attribute

On 8/4/20 2:46 AM, Jakub Jelinek wrote: Hi! When looking at the symver attr documentation in html, I found there is no name to refer to for it. The following patch fixes that, bootstrapped on x86_64-linux, ok for trunk and 10.3? 2020-08-04 Jakub Jelinek * doc/extend.texi (symver): A

[PATCH] doc: Add @cindex to symver attribute

Hi! When looking at the symver attr documentation in html, I found there is no name to refer to for it. The following patch fixes that, bootstrapped on x86_64-linux, ok for trunk and 10.3? 2020-08-04 Jakub Jelinek * doc/extend.texi (symver): Add @cindex for symver function attribute.

Re: [PATCH] Fix symver attribute with LTO

> On Wed, 2019-12-18 at 10:26 +0100, Jan Hubicka wrote: > > Hi, > > sorry I forgot to include cgraph and varpool changes in the patch. > > > > Index: varpool.c > > === > > --- varpool.c (revision 279467) > > +++ varpool.c

Re: [PATCH] Fix symver attribute with LTO

On Wed, 2019-12-18 at 10:26 +0100, Jan Hubicka wrote: > Hi, > sorry I forgot to include cgraph and varpool changes in the patch. > > Index: varpool.c > === > --- varpool.c (revision 279467) > +++ varpool.c (working copy) > @@ -539,8 +

Re: [PATCH] Fix symver attribute with LTO

> On 2019-12-19 19:12 +0800, Xi Ruoyao wrote: > > On 2019-12-19 11:06 +0100, Jan Hubicka wrote: > > > - /* See if we have linker information about symbol not being used or > > > - if we need to make guess based on the declaration. > > > + /* Limitation of gas requires us to output targets of

Re: [PATCH] Fix symver attribute with LTO

On 2019-12-19 19:12 +0800, Xi Ruoyao wrote: > On 2019-12-19 11:06 +0100, Jan Hubicka wrote: > > - /* See if we have linker information about symbol not being used or > > - if we need to make guess based on the declaration. > > + /* Limitation of gas requires us to output targets of symver ali

Re: [PATCH] Fix symver attribute with LTO

nd thus does not really fit for the check. > Lastly we can not rely on symver attribute to still be present here. > > Regtested x86_64-linux and comitted. > Honza > * cgraph.c (cgraph_node_cannot_be_local_p_1): Prevent targets of > symver attributes to be localiz

Re: [PATCH] Fix symver attribute with LTO

oved the checks away rom used_from_object_file. This function is about non-LTO objects linked into the DSO and thus does not really fit for the check. Lastly we can not rely on symver attribute to still be present here. Regtested x86_64-linux and comitted. Honza * cgraph.c (cgraph_node_

Re: [PATCH] Fix symver attribute with LTO

On 2019-12-18 14:19 +0100, Jan Hubicka wrote: > The problem here is that we lie to the compiler (by pretending that > foo_v2 is exported from DSO while it is not) and force user to do the > same. > > We support two ways to hide symbol - either at compile time via > attribute((visibility("hidden"))

Re: [PATCH] Fix symver attribute with LTO

On 2019-12-18 14:19 +0100, Jan Hubicka wrote: > > ICE here. > > > > lto1: internal compiler error: tree check: expected identifier_node, have > > function_decl in ultimate_transparent_alias_target, at varasm.c:1308 > > 0x6f9cfe tree_check_failed(tree_node const*, char const*, int, char const*, > >

Re: [PATCH] Fix symver attribute with LTO

> ICE here. > > lto1: internal compiler error: tree check: expected identifier_node, have > function_decl in ultimate_transparent_alias_target, at varasm.c:1308 > 0x6f9cfe tree_check_failed(tree_node const*, char const*, int, char const*, > ...) > ../../gcc/gcc/tree.c:9685 > 0x714541 tree_c

Re: [PATCH] Fix symver attribute with LTO

On 2019-12-18 10:26 +0100, Jan Hubicka wrote: > Hi, > sorry I forgot to include cgraph and varpool changes in the patch. > > Index: varpool.c > === > --- varpool.c (revision 279467) > +++ varpool.c (working copy) > @@ -539,8 +539,7 @@

Re: [PATCH] Fix symver attribute with LTO

Hi, sorry I forgot to include cgraph and varpool changes in the patch. Index: varpool.c === --- varpool.c (revision 279467) +++ varpool.c (working copy) @@ -539,8 +539,7 @@ varpool_node::assemble_aliases (void) { varpo

Re: [PATCH] Fix symver attribute with LTO

On 2019-12-17 18:47 +0100, Jan Hubicka wrote: > > Would it be equivalent to: > > 1) output foo_v2 local > > 2) producing static alias with local name (.L1) > > 3) do .symver .L1,foo@@@VERS_2 > > That is somewhat more systematic and would not lead to false > > visibilities. > > I spent some time pl

Re: [PATCH] Fix symver attribute with LTO

> Would it be equivalent to: > 1) output foo_v2 local > 2) producing static alias with local name (.L1) > 3) do .symver .L1,foo@@@VERS_2 > That is somewhat more systematic and would not lead to false > visibilities. I spent some time playing with this. An in order to 1) be able to handle foo_v2

Re: [PATCH] Fix symver attribute with LTO

> Hi Jan, > > I'm using GNU ld 2.33.1. > > I'll attach a testcase simplified from fuse-3.9 code. "local: *;" in the > versioning script triggers the issue. Without it there would be no problem. Thanks. You are right that I did not play with local:. Now I wonder what is the intended behaviour h

Re: [PATCH] Fix symver attribute with LTO

On 2019-12-17 09:32 +0100, Jan Hubicka wrote: > > Hi, > > with Jan's patch commited in r278878 we can use symver attribute for > > functions > > and variables. The symver attribute is designed for replacing toplevel asm > > statements containing &q

Re: [PATCH] Fix symver attribute with LTO

> Hi, > with Jan's patch commited in r278878 we can use symver attribute for functions > and variables. The symver attribute is designed for replacing toplevel asm > statements containing ".symver" which may be removed by LTO. Unfortunately, > a quick test shown GCC

[PATCH] Fix symver attribute with LTO

Hi, with Jan's patch commited in r278878 we can use symver attribute for functions and variables. The symver attribute is designed for replacing toplevel asm statements containing ".symver" which may be removed by LTO. Unfortunately, a quick test shown GCC still generates buggy s

Re: Symver attribute

t but found it is bit non-trivial since > > > > currently way we need to attach the attribute to definition itself, > > > > while current .symver output is done in separate C++ files. > > What is the reason for this limitation? I think that is pretty severe. > Wouldn't

Re: Symver attribute

l since > > > currently way we need to attach the attribute to definition itself, > > > while current .symver output is done in separate C++ files. What is the reason for this limitation? I think that is pretty severe. Wouldn't it be enough to accept symver attribute on any de

Re: Symver attribute

> > It would be great to convert libstdc++ to the new infrastructure so it > > becomes LTO safe and gives some real world testing to this > > infrastructure. I tried that but found it is bit non-trivial since > > currently way we need to attach the attribute to definition itself, > > while current

Re: Symver attribute

On 30/11/19 22:13 +0100, Jan Hubicka wrote: Hi, this is patch incorporating (I hope) all the suggestions and corrections which I applied. I will work incremnetaly on supporting the name@@@node semantics which is bit different from @ and @@ one by actually removing the original symbol. Here I ne

Re: Symver attribute

. (symtab_node::resolve_alias): Handle symver. * varasm.c (do_assemble_symver): New function. * varpool.c (varpool_node::assemble_aliases): Use it. * doc/extend.texi: (symver attribute): Document. * config/elfos.h (ASM_OUTPUT_SYMVER_DIRECTIVE): New. c-family

Re: Symver attribute

> On Sat, 30 Nov 2019, Jan Hubicka wrote: > > > > I'd rather GCC created those aliases automatically (with names that can't > > > be used as C symbols, e.g. containing '.', if possible, or failing that > > > implementation-namespace names that are unlikely to conflict with C > > > symbols), so

Re: Symver attribute

On Sat, 30 Nov 2019, Jan Hubicka wrote: > > I'd rather GCC created those aliases automatically (with names that can't > > be used as C symbols, e.g. containing '.', if possible, or failing that > > implementation-namespace names that are unlikely to conflict with C > > symbols), so that the API

Re: Symver attribute

Hi, > > +static tree > > +handle_symver_attribute (tree *node, tree ARG_UNUSED (name), tree args, > > +int ARG_UNUSED (flags), bool *no_add_attrs) > > +{ > > + tree symver; > > + const char *symver_str; > > + > > + if (TREE_CODE (*node) != FUNCTION_DECL && TREE_CODE (*node) !

Re: Symver attribute

> On Fri, 15 Nov 2019, Jan Hubicka wrote: > > > I was originaly supporting multiple symvers like: > > __attribute__ ((__symver__ ("foo@VERS_1"))) int > > __attribute__ ((__symver__ ("foo@VERS_2"))) int > > foo_v1 (void) > > { > > } > > > > but then noticed it is rejected by gas. > > That's

Re: Symver attribute

gt; (name), tree args, > { >tree symver; >const char *symver_str; > - unsigned n; > >if (TREE_CODE (*node) != FUNCTION_DECL && TREE_CODE (*node) != VAR_DECL) > { >warning (OPT_Wattributes, > -"symver attribute is

Re: Symver attribute

h, I thought this would happen for various things from libc as well, so > there would be a lot of random fallout. I probably misunderstood :-) glibc so far uses inline asm with .symver directives. That could change one day of course conditionally to use the GCC symver attribute. Jakub

Re: Symver attribute

On Tue, Nov 19, 2019 at 03:53:43PM +0100, Jan Hubicka wrote: > > Sounds perfectly fine to me, but how many tests will need changing? Is > > it only those that use symbol versioning directly? > > There are no tests presently, I plan to write some so those will get > dg-require-symver. > > .symver

Re: Symver attribute

> On Tue, Nov 19, 2019 at 07:29:37AM +0100, Jan Hubicka wrote: > > Current patch makes GCC to accept symver attribute on all ELF targets > > and simply output .symver directive into the assembly file hoping for > > the best. I hope that is acceptable since user will be info

Re: Symver attribute

On Tue, Nov 19, 2019 at 07:29:37AM +0100, Jan Hubicka wrote: > Current patch makes GCC to accept symver attribute on all ELF targets > and simply output .symver directive into the assembly file hoping for > the best. I hope that is acceptable since user will be informed by > assembler

Re: Symver attribute

hink the information is > available when GCC is built, beyond (a) it's definitely not supported for > non-ELF targets (as determined through by a list of targets such as in > config/elf.m4:ACX_ELF_TARGET_IFELSE) and (b) there might be a list of ELF > OS targets known to lac

Re: Symver attribute

On Mon, 18 Nov 2019, Rainer Orth wrote: > So you certainly need such an effective-target test and, at least as > importantly, a configure test at build time that you can assemble, link, > and run a test correctly before enabling it in gcc. Just > unconditionally dropping it into elfos.h is wrong.

Re: Symver attribute

* Rainer Orth: > Florian Weimer writes: > >> * Rainer Orth: >> >>> Hi Jan, >>> Also I wonder for testsuite bits, I think I need to implement dl-require-symver and then use it to gate the individual tests? Or do we have some common way to check for ELF? >>> >>> there's a misundersta

Re: Symver attribute

Florian Weimer writes: > * Rainer Orth: > >> Hi Jan, >> >>> Also I wonder for testsuite bits, I think I need to implement >>> dl-require-symver and then use it to gate the individual tests? Or do we >>> have some common way to check for ELF? >> >> there's a misunderstanding throughout here: symbo

Re: Symver attribute

Hi Jan, > thanks for feedback. Here is updated patch that incorporates Martin's > changes, formatting corrections and makes symvers of aliases work. just a few nits. > Index: doc/extend.texi > === > --- doc/extend.texi (revision 2

Re: Symver attribute

* Rainer Orth: > Hi Jan, > >> Also I wonder for testsuite bits, I think I need to implement >> dl-require-symver and then use it to gate the individual tests? Or do we >> have some common way to check for ELF? > > there's a misunderstanding throughout here: symbol versioning is *not* a > (generic)

Re: Symver attribute

Hi Jan, > Also I wonder for testsuite bits, I think I need to implement > dl-require-symver and then use it to gate the individual tests? Or do we > have some common way to check for ELF? there's a misunderstanding throughout here: symbol versioning is *not* a (generic) ELF feature, i.e. it is no

Re: Symver attribute

e; + return NULL_TREE; + } + + symver_str = TREE_STRING_POINTER (symver); + + int ats = 0; + for (int n = 0; n < TREE_STRING_LENGTH (symver); n++) + if (symver_str[n] == '@') + ats++; + + if (ats != 1 &&

Re: Symver attribute

On Fri, 15 Nov 2019, Jan Hubicka wrote: > I was originaly supporting multiple symvers like: > __attribute__ ((__symver__ ("foo@VERS_1"))) int > __attribute__ ((__symver__ ("foo@VERS_2"))) int > foo_v1 (void) > { > } > > but then noticed it is rejected by gas. That's

Re: Symver attribute

r : 1; /* Set once the definition was analyzed. The list of references and other properties are built during analysis. */ unsigned analyzed : 1; Index: cgraphunit.c === --- cgraphunit.c(revision 278293) +++ cgra

Re: Symver attribute

+2338,11 @@ handle_symver_attribute (tree *node, tree ARG_UNUSED (name), tree args, { tree symver; const char *symver_str; - unsigned n; if (TREE_CODE (*node) != FUNCTION_DECL && TREE_CODE (*node) != VAR_DECL) { warning (OPT_Wattributes, - "symver attr

Re: Symver attribute

On 11/15/19 10:05 AM, Jan Hubicka wrote: Index: params.opt === --- params.opt (revision 278220) +++ params.opt (working copy) @@ -483,7 +483,7 @@ Common Joined UInteger Var(param_max_inl The maximum number of instructions in a si

Re: Symver attribute

* Jan Hubicka: >> It's sometimes useful to define multiple versions for a single symbol. >> For maximum binutils compatibility, you would have to use intermediate >> aliases. __attribute__ ((__symver__ ("foo@VERS_1", "foo@@VERS_2"))) >> could turn into this: >> >> .set foo_v1.symver.1, foo_v1

Re: Symver attribute

> * Jan Hubicka: > > > Internally the patch tries to mimic what happens in ELF. In particular > > > > __attribute__ ((__symver__ ("foo@VERS_1"))) int > > foo_v1 (void) > > { > > } > > > > creates a special form of alias with symver flag. Its assembler name is > > foo@VERS_1 since it is what happe

Re: Symver attribute

* Jan Hubicka: > Internally the patch tries to mimic what happens in ELF. In particular > > __attribute__ ((__symver__ ("foo@VERS_1"))) int > foo_v1 (void) > { > } > > creates a special form of alias with symver flag. Its assembler name is > foo@VERS_1 since it is what happens in ELF too (normall

Symver attribute

Hi, this patch implements symver attribute which can be use din place of .symver directive and is LTO friendly. I would welcome feedback for this, in particular some evidence that codebases can be easily converted to use it. There is some discussion in the PR and its duplicate filled by Carlos