Re: Symver attribute

> On Mon, Dec 02, 2019 at 01:53:09PM +0100, Jan Hubicka wrote: > > > > 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 > > > > curren

Re: Symver attribute

On Mon, Dec 02, 2019 at 01:53:09PM +0100, Jan Hubicka wrote: > > > 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

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

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 need to change assembler name of the symbol itse

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

> On 11/15/19 10:05 AM, Jan Hubicka wrote: > > I am by no means expert in the area so feedback is welcome. I would > > like to get the patch to trunk early next week if it works well. > > Thank you Honza for the patch. The idea looks nice to me and I have just > few comments: > > 1) we should al

Re: Symver attribute

On Tue, Nov 19, 2019 at 10:19:05AM -0600, Segher Boessenkool wrote: > 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 prese

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 informed by > > assembler th

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 that symver

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

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

On 11/15/19 9:04 AM, Jan Hubicka wrote: Hi, thanks for feedback. Here is updated patch that incorporates Martin's changes, formatting corrections and makes symvers of aliases work. Just a couple of questions and a few minor nits, mostly having to do with my favorite subject of quoting things in

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

Hi, thanks for feedback. Here is updated patch that incorporates Martin's changes, formatting corrections and makes symvers of aliases work. Honza * c-family/c-attribs.c (handle_symver_attribute): New. (c_common_attribytes): Add symver. * cgraph.h (symtab_node): Add symver

Re: Symver attribute

On 11/15/19 10:05 AM, Jan Hubicka wrote: I am by no means expert in the area so feedback is welcome. I would like to get the patch to trunk early next week if it works well. Thank you Honza for the patch. The idea looks nice to me and I have just few comments: 1) we should also support foo@@@

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