add new option -fnovisibility for clang

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

add new option -fnovisibility for clang

Hollman, Daisy Sophia via cfe-dev
Hi All,

  In IBM compiler Xlclang , there is option -fnovisibiilty. The option is description as
  https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_visibility.html 
 
  we need to add the option -fnovisibiilty for clang in the IBM AIX OS(and the option is enabled by default in AIX OS).  
  I will implement the option in the other OS platform.(but the option is disabled by default in other OS).
 
  For example, the file test.c
 
 bash-4.2$ test.c
 __attribute__((visibility ("protected"))) int b;
 
 1 In AIX OS:
 
 1.1 Compiled with
 
  clang -fnovisibility    -target powerpc-unknown-aix  -emit-llvm  -S test.c
 or  
  clang -target powerpc-unknown-aix  -emit-llvm  -S test.c  ( the -fnovisibility is enabled by default in AIX OS)

 Generate IR as :
 
  @b = global i32 0, align 4
 
 1.2 Compiled with
  (If have "-fnovisibility  -fvisibility=*" at the same time.  the compile will ignore the -fnovisibility). 
 
  clang -fnovisibility  -fvisibility=default   -target powerpc-unknown-aix   -emit-llvm  -S test.c

Or

  clang -fvisibility=default   -target powerpc-unknown-aix   -emit-llvm  -S test.c
 
  Generate IR as :
  @b = protected global i32 0, align 4
 
 2. In Other OS(not AIX)
   2.1 clang -fnovisibility    -target powerpc-unknown-linux  -emit-llvm  -S test.c
   
    Generate IR as :
    @b = global i32 0, align 4

  2.2
    clang -target powerpc-unknown-linux  -emit-llvm  -S test.c ( the -fnovisibility is disabled by default in not AIX OS)
  Or
    (if have "-fnovisibility  -fvisibility=*" at the same time.  the compile will ignore the -fnovisibility).
    clang -fnovisibility  -fvisibility=default   -target powerpc-unknown-linux   -emit-llvm  -S test.c
  Or
    clang -fvisibility=default   -target powerpc-unknown-linux   -emit-llvm  -S test.c
   
   Generate IR as :
    @b = protected global i32 0, align 4  

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: add new option -fnovisibility for clang

Hollman, Daisy Sophia via cfe-dev

That name is terrible; if we’re going to add this, the canonical name should be something like -fignore-visibility-attributes. (We can also accept an alias if you need it.)

 

In terms of the functionality, it seems a little weird; cross-platform projects usually use macros for this sort of thing.  And I’m a little worried we’ll eventually need to add an attribute to override the flag, and then we’ll need flag to override that attribute, etc.  But if we need it for compatibility with existing AIX compilers, it’s hard to argue with that.

 

-Eli

 

From: cfe-dev <[hidden email]> On Behalf Of digger lin via cfe-dev
Sent: Thursday, September 10, 2020 7:04 AM
To: [hidden email]
Subject: [EXT] [cfe-dev] add new option -fnovisibility for clang

 

Hi All,

  In IBM compiler Xlclang , there is option -fnovisibiilty. The option is description as
  https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_visibility.html 
 
  we need to add the option -fnovisibiilty for clang in the IBM AIX OS(and the option is enabled by default in AIX OS).  
  I will implement the option in the other OS platform.(but the option is disabled by default in other OS).
 
  For example, the file test.c
 
 bash-4.2$ test.c
 __attribute__((visibility ("protected"))) int b;
 
 1 In AIX OS:
 
 1.1 Compiled with
 
  clang -fnovisibility    -target powerpc-unknown-aix  -emit-llvm  -S test.c
 or  
  clang -target powerpc-unknown-aix  -emit-llvm  -S test.c  ( the -fnovisibility is enabled by default in AIX OS)

 Generate IR as :
 
  @b = global i32 0, align 4
 
 1.2 Compiled with
  (If have "-fnovisibility  -fvisibility=*" at the same time.  the compile will ignore the -fnovisibility). 

 
  clang -fnovisibility  -fvisibility=default   -target powerpc-unknown-aix   -emit-llvm  -S test.c

Or

  clang -fvisibility=default   -target powerpc-unknown-aix   -emit-llvm  -S test.c
 
  Generate IR as :
  @b = protected global i32 0, align 4
 
 2. In Other OS(not AIX)
   2.1 clang -fnovisibility    -target powerpc-unknown-linux  -emit-llvm  -S test.c
   
    Generate IR as :
    @b = global i32 0, align 4

  2.2
    clang -target powerpc-unknown-linux  -emit-llvm  -S test.c ( the -fnovisibility is disabled by default in not AIX OS)
  Or
    (if have "-fnovisibility  -fvisibility=*" at the same time.  the compile will ignore the -fnovisibility).
    clang -fnovisibility  -fvisibility=default   -target powerpc-unknown-linux   -emit-llvm  -S test.c
  Or
    clang -fvisibility=default   -target powerpc-unknown-linux   -emit-llvm  -S test.c
   
   Generate IR as :
    @b = protected global i32 0, align 4  


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: add new option -fnovisibility for clang

Hollman, Daisy Sophia via cfe-dev
On Thu, Sep 10, 2020 at 4:01 PM Eli Friedman via cfe-dev <[hidden email]> wrote:

That name is terrible; if we’re going to add this, the canonical name should be something like -fignore-visibility-attributes. (We can also accept an alias if you need it.)

We won't require an alias. The XL compiler option was not "-fnovisibility".
 

 

In terms of the functionality, it seems a little weird; cross-platform projects usually use macros for this sort of thing.  And I’m a little worried we’ll eventually need to add an attribute to override the flag, and then we’ll need flag to override that attribute, etc.  But if we need it for compatibility with existing AIX compilers, it’s hard to argue with that.

 

-Eli

 

From: cfe-dev <[hidden email]> On Behalf Of digger lin via cfe-dev
Sent: Thursday, September 10, 2020 7:04 AM
To: [hidden email]
Subject: [EXT] [cfe-dev] add new option -fnovisibility for clang

 

Hi All,

  In IBM compiler Xlclang , there is option -fnovisibiilty. The option is description as
  https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_visibility.html 
 
  we need to add the option -fnovisibiilty for clang in the IBM AIX OS(and the option is enabled by default in AIX OS).  
  I will implement the option in the other OS platform.(but the option is disabled by default in other OS).
 
  For example, the file test.c
 
 bash-4.2$ test.c
 __attribute__((visibility ("protected"))) int b;
 
 1 In AIX OS:
 
 1.1 Compiled with
 
  clang -fnovisibility    -target powerpc-unknown-aix  -emit-llvm  -S test.c
 or  
  clang -target powerpc-unknown-aix  -emit-llvm  -S test.c  ( the -fnovisibility is enabled by default in AIX OS)

 Generate IR as :
 
  @b = global i32 0, align 4
 
 1.2 Compiled with
  (If have "-fnovisibility  -fvisibility=*" at the same time.  the compile will ignore the -fnovisibility). 

 
  clang -fnovisibility  -fvisibility=default   -target powerpc-unknown-aix   -emit-llvm  -S test.c

Or

  clang -fvisibility=default   -target powerpc-unknown-aix   -emit-llvm  -S test.c
 
  Generate IR as :
  @b = protected global i32 0, align 4
 
 2. In Other OS(not AIX)
   2.1 clang -fnovisibility    -target powerpc-unknown-linux  -emit-llvm  -S test.c
   
    Generate IR as :
    @b = global i32 0, align 4

  2.2
    clang -target powerpc-unknown-linux  -emit-llvm  -S test.c ( the -fnovisibility is disabled by default in not AIX OS)
  Or
    (if have "-fnovisibility  -fvisibility=*" at the same time.  the compile will ignore the -fnovisibility).
    clang -fnovisibility  -fvisibility=default   -target powerpc-unknown-linux   -emit-llvm  -S test.c
  Or
    clang -fvisibility=default   -target powerpc-unknown-linux   -emit-llvm  -S test.c
   
   Generate IR as :
    @b = protected global i32 0, align 4  

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: add new option -fnovisibility for clang

Hollman, Daisy Sophia via cfe-dev
In reply to this post by Hollman, Daisy Sophia via cfe-dev
But why does AIX want to ignore visibility restrictions encoded via attribute? Especially by default?

On Thu, Sep 10, 2020 at 10:04 AM digger lin via cfe-dev <[hidden email]> wrote:
Hi All,

  In IBM compiler Xlclang , there is option -fnovisibiilty. The option is description as
  https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_visibility.html 
 
  we need to add the option -fnovisibiilty for clang in the IBM AIX OS(and the option is enabled by default in AIX OS).  
  I will implement the option in the other OS platform.(but the option is disabled by default in other OS).
 
  For example, the file test.c
 
 bash-4.2$ test.c
 __attribute__((visibility ("protected"))) int b;
 
 1 In AIX OS:
 
 1.1 Compiled with
 
  clang -fnovisibility    -target powerpc-unknown-aix  -emit-llvm  -S test.c
 or  
  clang -target powerpc-unknown-aix  -emit-llvm  -S test.c  ( the -fnovisibility is enabled by default in AIX OS)

 Generate IR as :
 
  @b = global i32 0, align 4
 
 1.2 Compiled with
  (If have "-fnovisibility  -fvisibility=*" at the same time.  the compile will ignore the -fnovisibility). 
 
  clang -fnovisibility  -fvisibility=default   -target powerpc-unknown-aix   -emit-llvm  -S test.c

Or

  clang -fvisibility=default   -target powerpc-unknown-aix   -emit-llvm  -S test.c
 
  Generate IR as :
  @b = protected global i32 0, align 4
 
 2. In Other OS(not AIX)
   2.1 clang -fnovisibility    -target powerpc-unknown-linux  -emit-llvm  -S test.c
   
    Generate IR as :
    @b = global i32 0, align 4

  2.2
    clang -target powerpc-unknown-linux  -emit-llvm  -S test.c ( the -fnovisibility is disabled by default in not AIX OS)
  Or
    (if have "-fnovisibility  -fvisibility=*" at the same time.  the compile will ignore the -fnovisibility).
    clang -fnovisibility  -fvisibility=default   -target powerpc-unknown-linux   -emit-llvm  -S test.c
  Or
    clang -fvisibility=default   -target powerpc-unknown-linux   -emit-llvm  -S test.c
   
   Generate IR as :
    @b = protected global i32 0, align 4  
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: add new option -fnovisibility for clang

Hollman, Daisy Sophia via cfe-dev
On Thu, Sep 10, 2020 at 6:30 PM James Y Knight via cfe-dev <[hidden email]> wrote:
But why does AIX want to ignore visibility restrictions encoded via attribute? Especially by default?
One reason is that AIX performs more early/less lazy symbol resolution (even with runtime linking) than, say, Linux. So, if a project goes with an export-by-default model (via attribute in some scope), they can cause link-time errors from symbol references to undefined symbols from code that would otherwise have been discarded as unreferenced by the linker. It seems such code is not uncommon (and has the questionable effect of exporting template instantiations based on "client provided" types that are not part of the "library"/"utility" code in question).

Now, if someone was porting their project to AIX, it is reasonable to ask them to figure out the problem with their less-than-discriminate usage of visibility. For developers trying to use packages with such problems, they're rather less interested in fixing the projects that they're dependent on.
 

On Thu, Sep 10, 2020 at 10:04 AM digger lin via cfe-dev <[hidden email]> wrote:
Hi All,

  In IBM compiler Xlclang , there is option -fnovisibiilty. The option is description as
  https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_visibility.html 
 
  we need to add the option -fnovisibiilty for clang in the IBM AIX OS(and the option is enabled by default in AIX OS).  
  I will implement the option in the other OS platform.(but the option is disabled by default in other OS).
 
  For example, the file test.c
 
 bash-4.2$ test.c
 __attribute__((visibility ("protected"))) int b;
 
 1 In AIX OS:
 
 1.1 Compiled with
 
  clang -fnovisibility    -target powerpc-unknown-aix  -emit-llvm  -S test.c
 or  
  clang -target powerpc-unknown-aix  -emit-llvm  -S test.c  ( the -fnovisibility is enabled by default in AIX OS)

 Generate IR as :
 
  @b = global i32 0, align 4
 
 1.2 Compiled with
  (If have "-fnovisibility  -fvisibility=*" at the same time.  the compile will ignore the -fnovisibility). 
 
  clang -fnovisibility  -fvisibility=default   -target powerpc-unknown-aix   -emit-llvm  -S test.c

Or

  clang -fvisibility=default   -target powerpc-unknown-aix   -emit-llvm  -S test.c
 
  Generate IR as :
  @b = protected global i32 0, align 4
 
 2. In Other OS(not AIX)
   2.1 clang -fnovisibility    -target powerpc-unknown-linux  -emit-llvm  -S test.c
   
    Generate IR as :
    @b = global i32 0, align 4

  2.2
    clang -target powerpc-unknown-linux  -emit-llvm  -S test.c ( the -fnovisibility is disabled by default in not AIX OS)
  Or
    (if have "-fnovisibility  -fvisibility=*" at the same time.  the compile will ignore the -fnovisibility).
    clang -fnovisibility  -fvisibility=default   -target powerpc-unknown-linux   -emit-llvm  -S test.c
  Or
    clang -fvisibility=default   -target powerpc-unknown-linux   -emit-llvm  -S test.c
   
   Generate IR as :
    @b = protected global i32 0, align 4  
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: add new option -fnovisibility for clang

Hollman, Daisy Sophia via cfe-dev


On Thu, Sep 10, 2020, 6:57 PM Hubert Tong <[hidden email]> wrote:
On Thu, Sep 10, 2020 at 6:30 PM James Y Knight via cfe-dev <[hidden email]> wrote:
But why does AIX want to ignore visibility restrictions encoded via attribute? Especially by default?
One reason is that AIX performs more early/less lazy symbol resolution (even with runtime linking) than, say, Linux. So, if a project goes with an export-by-default model (via attribute in some scope), they can cause link-time errors from symbol references to undefined symbols from code that would otherwise have been discarded as unreferenced by the linker. It seems such code is not uncommon (and has the questionable effect of exporting template instantiations based on "client provided" types that are not part of the "library"/"utility" code in question).

But, the default visibility is "default" -- which is the most export-y visibility setting there is. So, without specifying visibility options on the command line, the only thing you can do with visibility attributes in code is to remove exports, not add additional ones.

What am I missing?

Now, if someone was porting their project to AIX, it is reasonable to ask them to figure out the problem with their less-than-discriminate usage of visibility. For developers trying to use packages with such problems, they're rather less interested in fixing the projects that they're dependent on.
 

On Thu, Sep 10, 2020 at 10:04 AM digger lin via cfe-dev <[hidden email]> wrote:
Hi All,

  In IBM compiler Xlclang , there is option -fnovisibiilty. The option is description as
  https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_visibility.html 
 
  we need to add the option -fnovisibiilty for clang in the IBM AIX OS(and the option is enabled by default in AIX OS).  
  I will implement the option in the other OS platform.(but the option is disabled by default in other OS).
 
  For example, the file test.c
 
 bash-4.2$ test.c
 __attribute__((visibility ("protected"))) int b;
 
 1 In AIX OS:
 
 1.1 Compiled with
 
  clang -fnovisibility    -target powerpc-unknown-aix  -emit-llvm  -S test.c
 or  
  clang -target powerpc-unknown-aix  -emit-llvm  -S test.c  ( the -fnovisibility is enabled by default in AIX OS)

 Generate IR as :
 
  @b = global i32 0, align 4
 
 1.2 Compiled with
  (If have "-fnovisibility  -fvisibility=*" at the same time.  the compile will ignore the -fnovisibility). 
 
  clang -fnovisibility  -fvisibility=default   -target powerpc-unknown-aix   -emit-llvm  -S test.c

Or

  clang -fvisibility=default   -target powerpc-unknown-aix   -emit-llvm  -S test.c
 
  Generate IR as :
  @b = protected global i32 0, align 4
 
 2. In Other OS(not AIX)
   2.1 clang -fnovisibility    -target powerpc-unknown-linux  -emit-llvm  -S test.c
   
    Generate IR as :
    @b = global i32 0, align 4

  2.2
    clang -target powerpc-unknown-linux  -emit-llvm  -S test.c ( the -fnovisibility is disabled by default in not AIX OS)
  Or
    (if have "-fnovisibility  -fvisibility=*" at the same time.  the compile will ignore the -fnovisibility).
    clang -fnovisibility  -fvisibility=default   -target powerpc-unknown-linux   -emit-llvm  -S test.c
  Or
    clang -fvisibility=default   -target powerpc-unknown-linux   -emit-llvm  -S test.c
   
   Generate IR as :
    @b = protected global i32 0, align 4  
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: add new option -fnovisibility for clang

Hollman, Daisy Sophia via cfe-dev
Hi James,

I think the rationale is that by default, we want users to use an `export list` to manually control the symbol visibility on AIX instead of relying on the attribute in the code (which could cause unwanted effects as Hubert already described).
Not sure if that answers your question.

Thanks,

Jason Liu

On Thu, Sep 10, 2020 at 9:07 PM James Y Knight via cfe-dev <[hidden email]> wrote:


On Thu, Sep 10, 2020, 6:57 PM Hubert Tong <[hidden email]> wrote:
On Thu, Sep 10, 2020 at 6:30 PM James Y Knight via cfe-dev <[hidden email]> wrote:
But why does AIX want to ignore visibility restrictions encoded via attribute? Especially by default?
One reason is that AIX performs more early/less lazy symbol resolution (even with runtime linking) than, say, Linux. So, if a project goes with an export-by-default model (via attribute in some scope), they can cause link-time errors from symbol references to undefined symbols from code that would otherwise have been discarded as unreferenced by the linker. It seems such code is not uncommon (and has the questionable effect of exporting template instantiations based on "client provided" types that are not part of the "library"/"utility" code in question).

But, the default visibility is "default" -- which is the most export-y visibility setting there is. So, without specifying visibility options on the command line, the only thing you can do with visibility attributes in code is to remove exports, not add additional ones.

What am I missing?

Now, if someone was porting their project to AIX, it is reasonable to ask them to figure out the problem with their less-than-discriminate usage of visibility. For developers trying to use packages with such problems, they're rather less interested in fixing the projects that they're dependent on.
 

On Thu, Sep 10, 2020 at 10:04 AM digger lin via cfe-dev <[hidden email]> wrote:
Hi All,

  In IBM compiler Xlclang , there is option -fnovisibiilty. The option is description as
  https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_visibility.html 
 
  we need to add the option -fnovisibiilty for clang in the IBM AIX OS(and the option is enabled by default in AIX OS).  
  I will implement the option in the other OS platform.(but the option is disabled by default in other OS).
 
  For example, the file test.c
 
 bash-4.2$ test.c
 __attribute__((visibility ("protected"))) int b;
 
 1 In AIX OS:
 
 1.1 Compiled with
 
  clang -fnovisibility    -target powerpc-unknown-aix  -emit-llvm  -S test.c
 or  
  clang -target powerpc-unknown-aix  -emit-llvm  -S test.c  ( the -fnovisibility is enabled by default in AIX OS)

 Generate IR as :
 
  @b = global i32 0, align 4
 
 1.2 Compiled with
  (If have "-fnovisibility  -fvisibility=*" at the same time.  the compile will ignore the -fnovisibility). 
 
  clang -fnovisibility  -fvisibility=default   -target powerpc-unknown-aix   -emit-llvm  -S test.c

Or

  clang -fvisibility=default   -target powerpc-unknown-aix   -emit-llvm  -S test.c
 
  Generate IR as :
  @b = protected global i32 0, align 4
 
 2. In Other OS(not AIX)
   2.1 clang -fnovisibility    -target powerpc-unknown-linux  -emit-llvm  -S test.c
   
    Generate IR as :
    @b = global i32 0, align 4

  2.2
    clang -target powerpc-unknown-linux  -emit-llvm  -S test.c ( the -fnovisibility is disabled by default in not AIX OS)
  Or
    (if have "-fnovisibility  -fvisibility=*" at the same time.  the compile will ignore the -fnovisibility).
    clang -fnovisibility  -fvisibility=default   -target powerpc-unknown-linux   -emit-llvm  -S test.c
  Or
    clang -fvisibility=default   -target powerpc-unknown-linux   -emit-llvm  -S test.c
   
   Generate IR as :
    @b = protected global i32 0, align 4  
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: add new option -fnovisibility for clang

Hollman, Daisy Sophia via cfe-dev
In reply to this post by Hollman, Daisy Sophia via cfe-dev
On Thu, Sep 10, 2020 at 10:30 PM Hubert Tong <[hidden email]> wrote:
On Thu, Sep 10, 2020 at 9:07 PM James Y Knight <[hidden email]> wrote:


On Thu, Sep 10, 2020, 6:57 PM Hubert Tong <[hidden email]> wrote:
On Thu, Sep 10, 2020 at 6:30 PM James Y Knight via cfe-dev <[hidden email]> wrote:
But why does AIX want to ignore visibility restrictions encoded via attribute? Especially by default?
One reason is that AIX performs more early/less lazy symbol resolution (even with runtime linking) than, say, Linux. So, if a project goes with an export-by-default model (via attribute in some scope), they can cause link-time errors from symbol references to undefined symbols from code that would otherwise have been discarded as unreferenced by the linker. It seems such code is not uncommon (and has the questionable effect of exporting template instantiations based on "client provided" types that are not part of the "library"/"utility" code in question).

But, the default visibility is "default" -- which is the most export-y visibility setting there is. So, without specifying visibility options on the command line, the only thing you can do with visibility attributes in code is to remove exports, not add additional ones.

What am I missing?
That AIX is not an ELF platform. AIX has a default visibility for XCOFF called "unspecified". This is because the ELF-based visibility options do not quite match the base case on AIX. That the most export-y visibility is named "default" at the source level is an ELF-ism.

But Clang doesn't have an "unspecified" visibility, only default, protected, and hidden. And this proposal doesn't propose to add one, either. So I don't see how this command-line option makes sense in Clang, right now.

Perhaps it would make sense if proposed as a component of a larger change to visibility handling in clang.

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: add new option -fnovisibility for clang

Hollman, Daisy Sophia via cfe-dev
On Fri, Sep 11, 2020 at 2:58 PM James Y Knight <[hidden email]> wrote:
On Thu, Sep 10, 2020 at 10:30 PM Hubert Tong <[hidden email]> wrote:
On Thu, Sep 10, 2020 at 9:07 PM James Y Knight <[hidden email]> wrote:


On Thu, Sep 10, 2020, 6:57 PM Hubert Tong <[hidden email]> wrote:
On Thu, Sep 10, 2020 at 6:30 PM James Y Knight via cfe-dev <[hidden email]> wrote:
But why does AIX want to ignore visibility restrictions encoded via attribute? Especially by default?
One reason is that AIX performs more early/less lazy symbol resolution (even with runtime linking) than, say, Linux. So, if a project goes with an export-by-default model (via attribute in some scope), they can cause link-time errors from symbol references to undefined symbols from code that would otherwise have been discarded as unreferenced by the linker. It seems such code is not uncommon (and has the questionable effect of exporting template instantiations based on "client provided" types that are not part of the "library"/"utility" code in question).

But, the default visibility is "default" -- which is the most export-y visibility setting there is. So, without specifying visibility options on the command line, the only thing you can do with visibility attributes in code is to remove exports, not add additional ones.

What am I missing?
That AIX is not an ELF platform. AIX has a default visibility for XCOFF called "unspecified". This is because the ELF-based visibility options do not quite match the base case on AIX. That the most export-y visibility is named "default" at the source level is an ELF-ism.

But Clang doesn't have an "unspecified" visibility, only default, protected, and hidden. And this proposal doesn't propose to add one, either. So I don't see how this command-line option makes sense in Clang, right now.
It makes sense for Clang on AIX if it improves the consistency of behaviour with other compilers on that platform. GCC on AIX does not support encoding visibility into XCOFF and the default behaviour of the IBM xlclang/xlclang++ compiler on AIX is to not encode visibility into XCOFF. That there will be future complementary changes does not seem to be a practical reason for leaving Clang gratuitously different on AIX from other AIX compilers.
 

Perhaps it would make sense if proposed as a component of a larger change to visibility handling in clang.

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: add new option -fnovisibility for clang

Hollman, Daisy Sophia via cfe-dev
In reply to this post by Hollman, Daisy Sophia via cfe-dev
Hi All,
 According to the response of the email, we decidle to change the option name as -mignore-xcoff-visibility , and the option only work on the AIX OS, for other no AIX OS, using the option will report an unsupport options error as:

clang   -mignore-xcoff-visibility   -target powerpc-unknown-linux  -emit-llvm  -S test.c
clang-12: error: unsupported option '-mignore-xcoff-visibility' for target 'powerpc-unknown-linux

in AIX OS
1.1  the option  -mignore-xcoff-visibility is enabled by default , if there is not -fvisibility=* and  -mignore-xcoff-visibility explicitly in the clang command .

  clang  -mignore-xcoff-visibility     -target powerpc-unknown-aix  -emit-llvm  -S test.c
 or  
  clang -target powerpc-unknown-aix  -emit-llvm  -S test.c  ( the - mignore-xcoff-visibility  is enabled by default in AIX OS)

 Generate IR as :
 
  @b = global i32 0, align 4  

1.2 if there is  -fvisibility=* explicitly but not -mignore-xcoff-visibility  explicitly in the clang command.  it will generate visibility attributes.

clang  -fvisibility=default   -target powerpc-unknown-aix   -emit-llvm  -S test.c

  Generate IR as :
  @b = protected global i32 0, align 4  

1.3  if there are  both  -fvisibility=* and  -mignore-xcoff-visibility  explicitly in the clang command. The option  "-mignore-xcoff-visibility" wins , it ignores the visibility attribute.
 clang  -mignore-xcoff-visibility   -fvisibility=default  -target powerpc-unknown-aix  -emit-llvm  -S test.c

 Generate IR as :
 
  @b = global i32 0, align 4 

Thanks
  
Digger


On Fri, Sep 11, 2020 at 10:02 AM Jason Liu <[hidden email]> wrote:
Hi James,

I think the rationale is that by default, we want users to use an `export list` to manually control the symbol visibility on AIX instead of relying on the attribute in the code (which could cause unwanted effects as Hubert already described).
Not sure if that answers your question.

Thanks,

Jason Liu

On Thu, Sep 10, 2020 at 9:07 PM James Y Knight via cfe-dev <[hidden email]> wrote:


On Thu, Sep 10, 2020, 6:57 PM Hubert Tong <[hidden email]> wrote:
On Thu, Sep 10, 2020 at 6:30 PM James Y Knight via cfe-dev <[hidden email]> wrote:
But why does AIX want to ignore visibility restrictions encoded via attribute? Especially by default?
One reason is that AIX performs more early/less lazy symbol resolution (even with runtime linking) than, say, Linux. So, if a project goes with an export-by-default model (via attribute in some scope), they can cause link-time errors from symbol references to undefined symbols from code that would otherwise have been discarded as unreferenced by the linker. It seems such code is not uncommon (and has the questionable effect of exporting template instantiations based on "client provided" types that are not part of the "library"/"utility" code in question).

But, the default visibility is "default" -- which is the most export-y visibility setting there is. So, without specifying visibility options on the command line, the only thing you can do with visibility attributes in code is to remove exports, not add additional ones.

What am I missing?

Now, if someone was porting their project to AIX, it is reasonable to ask them to figure out the problem with their less-than-discriminate usage of visibility. For developers trying to use packages with such problems, they're rather less interested in fixing the projects that they're dependent on.
 

On Thu, Sep 10, 2020 at 10:04 AM digger lin via cfe-dev <[hidden email]> wrote:
Hi All,

  In IBM compiler Xlclang , there is option -fnovisibiilty. The option is description as
  https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/compiler_ref/opt_visibility.html 
 
  we need to add the option -fnovisibiilty for clang in the IBM AIX OS(and the option is enabled by default in AIX OS).  
  I will implement the option in the other OS platform.(but the option is disabled by default in other OS).
 
  For example, the file test.c
 
 bash-4.2$ test.c
 __attribute__((visibility ("protected"))) int b;
 
 1 In AIX OS:
 
 1.1 Compiled with
 
  clang -fnovisibility    -target powerpc-unknown-aix  -emit-llvm  -S test.c
 or  
  clang -target powerpc-unknown-aix  -emit-llvm  -S test.c  ( the -fnovisibility is enabled by default in AIX OS)

 Generate IR as :
 
  @b = global i32 0, align 4
 
 1.2 Compiled with
  (If have "-fnovisibility  -fvisibility=*" at the same time.  the compile will ignore the -fnovisibility). 
 
  clang -fnovisibility  -fvisibility=default   -target powerpc-unknown-aix   -emit-llvm  -S test.c

Or

  clang -fvisibility=default   -target powerpc-unknown-aix   -emit-llvm  -S test.c
 
  Generate IR as :
  @b = protected global i32 0, align 4
 
 2. In Other OS(not AIX)
   2.1 clang -fnovisibility    -target powerpc-unknown-linux  -emit-llvm  -S test.c
   
    Generate IR as :
    @b = global i32 0, align 4

  2.2
    clang -target powerpc-unknown-linux  -emit-llvm  -S test.c ( the -fnovisibility is disabled by default in not AIX OS)
  Or
    (if have "-fnovisibility  -fvisibility=*" at the same time.  the compile will ignore the -fnovisibility).
    clang -fnovisibility  -fvisibility=default   -target powerpc-unknown-linux   -emit-llvm  -S test.c
  Or
    clang -fvisibility=default   -target powerpc-unknown-linux   -emit-llvm  -S test.c
   
   Generate IR as :
    @b = protected global i32 0, align 4  
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: add new option -fnovisibility for clang

Hollman, Daisy Sophia via cfe-dev
In reply to this post by Hollman, Daisy Sophia via cfe-dev
On Fri, Sep 11, 2020 at 3:55 PM Hubert Tong <[hidden email]> wrote:
On Fri, Sep 11, 2020 at 2:58 PM James Y Knight <[hidden email]> wrote:
On Thu, Sep 10, 2020 at 10:30 PM Hubert Tong <[hidden email]> wrote:
On Thu, Sep 10, 2020 at 9:07 PM James Y Knight <[hidden email]> wrote:


On Thu, Sep 10, 2020, 6:57 PM Hubert Tong <[hidden email]> wrote:
On Thu, Sep 10, 2020 at 6:30 PM James Y Knight via cfe-dev <[hidden email]> wrote:
But why does AIX want to ignore visibility restrictions encoded via attribute? Especially by default?
One reason is that AIX performs more early/less lazy symbol resolution (even with runtime linking) than, say, Linux. So, if a project goes with an export-by-default model (via attribute in some scope), they can cause link-time errors from symbol references to undefined symbols from code that would otherwise have been discarded as unreferenced by the linker. It seems such code is not uncommon (and has the questionable effect of exporting template instantiations based on "client provided" types that are not part of the "library"/"utility" code in question).

But, the default visibility is "default" -- which is the most export-y visibility setting there is. So, without specifying visibility options on the command line, the only thing you can do with visibility attributes in code is to remove exports, not add additional ones.

What am I missing?
That AIX is not an ELF platform. AIX has a default visibility for XCOFF called "unspecified". This is because the ELF-based visibility options do not quite match the base case on AIX. That the most export-y visibility is named "default" at the source level is an ELF-ism.

But Clang doesn't have an "unspecified" visibility, only default, protected, and hidden. And this proposal doesn't propose to add one, either. So I don't see how this command-line option makes sense in Clang, right now.
It makes sense for Clang on AIX if it improves the consistency of behaviour with other compilers on that platform. GCC on AIX does not support encoding visibility into XCOFF and the default behaviour of the IBM xlclang/xlclang++ compiler on AIX is to not encode visibility into XCOFF. That there will be future complementary changes does not seem to be a practical reason for leaving Clang gratuitously different on AIX from other AIX compilers.

If clang did not implement this feature, symbols marked visibility("hidden") or visibility("protected") will actually be marked hidden/protected in the output on AIX. If clang does implement this feature, such symbols will instead be marked as exported default-visibility. There is no change for symbols marked visibility("default").

So, the request here is that Clang on AIX should ignore the attempt to hide symbols, resulting in symbols being exported, even though the code thought it was hiding them? That's the desired behavior change?

I remain unclear as to how that is a useful or important feature. Are you worried about compatibility with code which incorrectly specified visibility("hidden"), when it actually did need to export the symbol?

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: add new option -fnovisibility for clang

Hollman, Daisy Sophia via cfe-dev
On Tue, Sep 15, 2020 at 11:21 AM James Y Knight via cfe-dev
<[hidden email]> wrote:

>
> On Fri, Sep 11, 2020 at 3:55 PM Hubert Tong <[hidden email]> wrote:
>>
>> On Fri, Sep 11, 2020 at 2:58 PM James Y Knight <[hidden email]> wrote:
>>>
>>> On Thu, Sep 10, 2020 at 10:30 PM Hubert Tong <[hidden email]> wrote:
>>>>
>>>> On Thu, Sep 10, 2020 at 9:07 PM James Y Knight <[hidden email]> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 10, 2020, 6:57 PM Hubert Tong <[hidden email]> wrote:
>>>>>>
>>>>>> On Thu, Sep 10, 2020 at 6:30 PM James Y Knight via cfe-dev <[hidden email]> wrote:
>>>>>>>
>>>>>>> But why does AIX want to ignore visibility restrictions encoded via attribute? Especially by default?
>>>>>>
>>>>>> One reason is that AIX performs more early/less lazy symbol resolution (even with runtime linking) than, say, Linux. So, if a project goes with an export-by-default model (via attribute in some scope), they can cause link-time errors from symbol references to undefined symbols from code that would otherwise have been discarded as unreferenced by the linker. It seems such code is not uncommon (and has the questionable effect of exporting template instantiations based on "client provided" types that are not part of the "library"/"utility" code in question).
>>>>>
>>>>>
>>>>> But, the default visibility is "default" -- which is the most export-y visibility setting there is. So, without specifying visibility options on the command line, the only thing you can do with visibility attributes in code is to remove exports, not add additional ones.
>>>>>
>>>>> What am I missing?
>>>>
>>>> That AIX is not an ELF platform. AIX has a default visibility for XCOFF called "unspecified". This is because the ELF-based visibility options do not quite match the base case on AIX. That the most export-y visibility is named "default" at the source level is an ELF-ism.
>>>
>>>
>>> But Clang doesn't have an "unspecified" visibility, only default, protected, and hidden. And this proposal doesn't propose to add one, either. So I don't see how this command-line option makes sense in Clang, right now.
>>
>> It makes sense for Clang on AIX if it improves the consistency of behaviour with other compilers on that platform. GCC on AIX does not support encoding visibility into XCOFF and the default behaviour of the IBM xlclang/xlclang++ compiler on AIX is to not encode visibility into XCOFF. That there will be future complementary changes does not seem to be a practical reason for leaving Clang gratuitously different on AIX from other AIX compilers.
>
>
> If clang did not implement this feature, symbols marked visibility("hidden") or visibility("protected") will actually be marked hidden/protected in the output on AIX. If clang does implement this feature, such symbols will instead be marked as exported default-visibility. There is no change for symbols marked visibility("default").
>
> So, the request here is that Clang on AIX should ignore the attempt to hide symbols, resulting in symbols being exported, even though the code thought it was hiding them? That's the desired behavior change?
>
> I remain unclear as to how that is a useful or important feature. Are you worried about compatibility with code which incorrectly specified visibility("hidden"), when it actually did need to export the symbol?

The same feeling here... Aren't most
__attribute__((visibility("hidden"))) guarded by macros? AIX can turn
off the macros...
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: add new option -fnovisibility for clang

Hollman, Daisy Sophia via cfe-dev
> I remain unclear as to how that is a useful or important feature. Are you worried about compatibility with code which incorrectly specified visibility("hidden"), when it actually did need to export the symbol?

I guess I understand the point of confusion, so I will try to clarify it a little bit. 
It goes back to Clang does not have "unspecified" visibility mapping yet. On AIX, the baseline visibility is not "default" or export. The baseline visibility is "unspecified" when no attribute is marked on the symbol. 
And -mignore-xcoff-visibility means let all the symbols have "unspecified" visibility, whether or not any visibility attribute is specified on the symbol. So that user could use export list in the link step to control the visibility on AIX, which gives a more fine-grained control. 
As it is right now, the llc on AIX actually treats `GlobalValue::DefaultVisibility` as "unspecified" as it is the baseline visibility mode on AIX. So it is a bit messy there, and we will need to clean that up when we add "unspecified" visibility attribute to clang for AIX. But I don't think it should prevent us from making the default behavior(unspecified visibility for all symbols) right on AIX for now. 
Hope that would clean up the confusion.


On Tue, Sep 15, 2020 at 2:35 PM Fāng-ruì Sòng via cfe-dev <[hidden email]> wrote:
On Tue, Sep 15, 2020 at 11:21 AM James Y Knight via cfe-dev
<[hidden email]> wrote:
>
> On Fri, Sep 11, 2020 at 3:55 PM Hubert Tong <[hidden email]> wrote:
>>
>> On Fri, Sep 11, 2020 at 2:58 PM James Y Knight <[hidden email]> wrote:
>>>
>>> On Thu, Sep 10, 2020 at 10:30 PM Hubert Tong <[hidden email]> wrote:
>>>>
>>>> On Thu, Sep 10, 2020 at 9:07 PM James Y Knight <[hidden email]> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 10, 2020, 6:57 PM Hubert Tong <[hidden email]> wrote:
>>>>>>
>>>>>> On Thu, Sep 10, 2020 at 6:30 PM James Y Knight via cfe-dev <[hidden email]> wrote:
>>>>>>>
>>>>>>> But why does AIX want to ignore visibility restrictions encoded via attribute? Especially by default?
>>>>>>
>>>>>> One reason is that AIX performs more early/less lazy symbol resolution (even with runtime linking) than, say, Linux. So, if a project goes with an export-by-default model (via attribute in some scope), they can cause link-time errors from symbol references to undefined symbols from code that would otherwise have been discarded as unreferenced by the linker. It seems such code is not uncommon (and has the questionable effect of exporting template instantiations based on "client provided" types that are not part of the "library"/"utility" code in question).
>>>>>
>>>>>
>>>>> But, the default visibility is "default" -- which is the most export-y visibility setting there is. So, without specifying visibility options on the command line, the only thing you can do with visibility attributes in code is to remove exports, not add additional ones.
>>>>>
>>>>> What am I missing?
>>>>
>>>> That AIX is not an ELF platform. AIX has a default visibility for XCOFF called "unspecified". This is because the ELF-based visibility options do not quite match the base case on AIX. That the most export-y visibility is named "default" at the source level is an ELF-ism.
>>>
>>>
>>> But Clang doesn't have an "unspecified" visibility, only default, protected, and hidden. And this proposal doesn't propose to add one, either. So I don't see how this command-line option makes sense in Clang, right now.
>>
>> It makes sense for Clang on AIX if it improves the consistency of behaviour with other compilers on that platform. GCC on AIX does not support encoding visibility into XCOFF and the default behaviour of the IBM xlclang/xlclang++ compiler on AIX is to not encode visibility into XCOFF. That there will be future complementary changes does not seem to be a practical reason for leaving Clang gratuitously different on AIX from other AIX compilers.
>
>
> If clang did not implement this feature, symbols marked visibility("hidden") or visibility("protected") will actually be marked hidden/protected in the output on AIX. If clang does implement this feature, such symbols will instead be marked as exported default-visibility. There is no change for symbols marked visibility("default").
>
> So, the request here is that Clang on AIX should ignore the attempt to hide symbols, resulting in symbols being exported, even though the code thought it was hiding them? That's the desired behavior change?
>
> I remain unclear as to how that is a useful or important feature. Are you worried about compatibility with code which incorrectly specified visibility("hidden"), when it actually did need to export the symbol?

The same feeling here... Aren't most
__attribute__((visibility("hidden"))) guarded by macros? AIX can turn
off the macros...
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: add new option -fnovisibility for clang

Hollman, Daisy Sophia via cfe-dev
> The same feeling here... Aren't most
> __attribute__((visibility("hidden"))) guarded by macros? AIX can turn
> off the macros...

I think we are not afraid of "hidden", but more afraid of symbols marked as __attribute__((visibility("default"))) getting exported.
And Hubert already explained why __attribute__((visibility("default"))) on symbols could be a problem on AIX in previous responses to this thread, so I don't need to repeat it here.
It's true that most of the time these attributes are guarded by macros, but it's not guaranteed and it could mean a lot of trouble to configure them correctly on AIX as well. 
So "ignoring" visibility attribute by default could actually work better in practice. If we are building an application, these visibility doesn't matter. If we are building a shared library, library owners might actually prefer to use an export list to control the symbol visibility on AIX. And users could still turn on the visibility feature on AIX if they understand the caveat associated with it. 

On Tue, Sep 15, 2020 at 3:28 PM Jason Liu <[hidden email]> wrote:
> I remain unclear as to how that is a useful or important feature. Are you worried about compatibility with code which incorrectly specified visibility("hidden"), when it actually did need to export the symbol?

I guess I understand the point of confusion, so I will try to clarify it a little bit. 
It goes back to Clang does not have "unspecified" visibility mapping yet. On AIX, the baseline visibility is not "default" or export. The baseline visibility is "unspecified" when no attribute is marked on the symbol. 
And -mignore-xcoff-visibility means let all the symbols have "unspecified" visibility, whether or not any visibility attribute is specified on the symbol. So that user could use export list in the link step to control the visibility on AIX, which gives a more fine-grained control. 
As it is right now, the llc on AIX actually treats `GlobalValue::DefaultVisibility` as "unspecified" as it is the baseline visibility mode on AIX. So it is a bit messy there, and we will need to clean that up when we add "unspecified" visibility attribute to clang for AIX. But I don't think it should prevent us from making the default behavior(unspecified visibility for all symbols) right on AIX for now. 
Hope that would clean up the confusion.


On Tue, Sep 15, 2020 at 2:35 PM Fāng-ruì Sòng via cfe-dev <[hidden email]> wrote:
On Tue, Sep 15, 2020 at 11:21 AM James Y Knight via cfe-dev
<[hidden email]> wrote:
>
> On Fri, Sep 11, 2020 at 3:55 PM Hubert Tong <[hidden email]> wrote:
>>
>> On Fri, Sep 11, 2020 at 2:58 PM James Y Knight <[hidden email]> wrote:
>>>
>>> On Thu, Sep 10, 2020 at 10:30 PM Hubert Tong <[hidden email]> wrote:
>>>>
>>>> On Thu, Sep 10, 2020 at 9:07 PM James Y Knight <[hidden email]> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 10, 2020, 6:57 PM Hubert Tong <[hidden email]> wrote:
>>>>>>
>>>>>> On Thu, Sep 10, 2020 at 6:30 PM James Y Knight via cfe-dev <[hidden email]> wrote:
>>>>>>>
>>>>>>> But why does AIX want to ignore visibility restrictions encoded via attribute? Especially by default?
>>>>>>
>>>>>> One reason is that AIX performs more early/less lazy symbol resolution (even with runtime linking) than, say, Linux. So, if a project goes with an export-by-default model (via attribute in some scope), they can cause link-time errors from symbol references to undefined symbols from code that would otherwise have been discarded as unreferenced by the linker. It seems such code is not uncommon (and has the questionable effect of exporting template instantiations based on "client provided" types that are not part of the "library"/"utility" code in question).
>>>>>
>>>>>
>>>>> But, the default visibility is "default" -- which is the most export-y visibility setting there is. So, without specifying visibility options on the command line, the only thing you can do with visibility attributes in code is to remove exports, not add additional ones.
>>>>>
>>>>> What am I missing?
>>>>
>>>> That AIX is not an ELF platform. AIX has a default visibility for XCOFF called "unspecified". This is because the ELF-based visibility options do not quite match the base case on AIX. That the most export-y visibility is named "default" at the source level is an ELF-ism.
>>>
>>>
>>> But Clang doesn't have an "unspecified" visibility, only default, protected, and hidden. And this proposal doesn't propose to add one, either. So I don't see how this command-line option makes sense in Clang, right now.
>>
>> It makes sense for Clang on AIX if it improves the consistency of behaviour with other compilers on that platform. GCC on AIX does not support encoding visibility into XCOFF and the default behaviour of the IBM xlclang/xlclang++ compiler on AIX is to not encode visibility into XCOFF. That there will be future complementary changes does not seem to be a practical reason for leaving Clang gratuitously different on AIX from other AIX compilers.
>
>
> If clang did not implement this feature, symbols marked visibility("hidden") or visibility("protected") will actually be marked hidden/protected in the output on AIX. If clang does implement this feature, such symbols will instead be marked as exported default-visibility. There is no change for symbols marked visibility("default").
>
> So, the request here is that Clang on AIX should ignore the attempt to hide symbols, resulting in symbols being exported, even though the code thought it was hiding them? That's the desired behavior change?
>
> I remain unclear as to how that is a useful or important feature. Are you worried about compatibility with code which incorrectly specified visibility("hidden"), when it actually did need to export the symbol?

The same feeling here... Aren't most
__attribute__((visibility("hidden"))) guarded by macros? AIX can turn
off the macros...
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: add new option -fnovisibility for clang

Hollman, Daisy Sophia via cfe-dev
In reply to this post by Hollman, Daisy Sophia via cfe-dev
On Tue, Sep 15, 2020 at 3:29 PM Jason Liu via cfe-dev <[hidden email]> wrote:
> I remain unclear as to how that is a useful or important feature. Are you worried about compatibility with code which incorrectly specified visibility("hidden"), when it actually did need to export the symbol?

I guess I understand the point of confusion, so I will try to clarify it a little bit. 
It goes back to Clang does not have "unspecified" visibility mapping yet. On AIX, the baseline visibility is not "default" or export. The baseline visibility is "unspecified" when no attribute is marked on the symbol. 

What is ultimately the behavior for "unspecified" symbols, when no export-list is provided by the user?

And -mignore-xcoff-visibility means let all the symbols have "unspecified" visibility, whether or not any visibility attribute is specified on the symbol. So that user could use export list in the link step to control the visibility on AIX, which gives a more fine-grained control. 

On GNU/ELF, the export-list functionality (called version-script there) allows you to remove symbols from the list to be exported, but not add them. So, visibility("default") marks it as potentially-exported, but the version-script can override and make the symbol hidden if it wants to.

Are you saying that on the existing AIX compilers/linkers, the export-list cannot be used to make a symbol "hidden" (non-exported), if it had been explicitly annotated visibility("default") in the source (assuming visibility declarations weren't being ignored)? That only "unspecified" symbols can be modified by the export-list?

 
As it is right now, the llc on AIX actually treats `GlobalValue::DefaultVisibility` as "unspecified" as it is the baseline visibility mode on AIX. So it is a bit messy there, and we will need to clean that up when we add "unspecified" visibility attribute to clang for AIX. But I don't think it should prevent us from making the default behavior(unspecified visibility for all symbols) right on AIX for now. 
Hope that would clean up the confusion.


On Tue, Sep 15, 2020 at 2:35 PM Fāng-ruì Sòng via cfe-dev <[hidden email]> wrote:
On Tue, Sep 15, 2020 at 11:21 AM James Y Knight via cfe-dev
<[hidden email]> wrote:
>
> On Fri, Sep 11, 2020 at 3:55 PM Hubert Tong <[hidden email]> wrote:
>>
>> On Fri, Sep 11, 2020 at 2:58 PM James Y Knight <[hidden email]> wrote:
>>>
>>> On Thu, Sep 10, 2020 at 10:30 PM Hubert Tong <[hidden email]> wrote:
>>>>
>>>> On Thu, Sep 10, 2020 at 9:07 PM James Y Knight <[hidden email]> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 10, 2020, 6:57 PM Hubert Tong <[hidden email]> wrote:
>>>>>>
>>>>>> On Thu, Sep 10, 2020 at 6:30 PM James Y Knight via cfe-dev <[hidden email]> wrote:
>>>>>>>
>>>>>>> But why does AIX want to ignore visibility restrictions encoded via attribute? Especially by default?
>>>>>>
>>>>>> One reason is that AIX performs more early/less lazy symbol resolution (even with runtime linking) than, say, Linux. So, if a project goes with an export-by-default model (via attribute in some scope), they can cause link-time errors from symbol references to undefined symbols from code that would otherwise have been discarded as unreferenced by the linker. It seems such code is not uncommon (and has the questionable effect of exporting template instantiations based on "client provided" types that are not part of the "library"/"utility" code in question).
>>>>>
>>>>>
>>>>> But, the default visibility is "default" -- which is the most export-y visibility setting there is. So, without specifying visibility options on the command line, the only thing you can do with visibility attributes in code is to remove exports, not add additional ones.
>>>>>
>>>>> What am I missing?
>>>>
>>>> That AIX is not an ELF platform. AIX has a default visibility for XCOFF called "unspecified". This is because the ELF-based visibility options do not quite match the base case on AIX. That the most export-y visibility is named "default" at the source level is an ELF-ism.
>>>
>>>
>>> But Clang doesn't have an "unspecified" visibility, only default, protected, and hidden. And this proposal doesn't propose to add one, either. So I don't see how this command-line option makes sense in Clang, right now.
>>
>> It makes sense for Clang on AIX if it improves the consistency of behaviour with other compilers on that platform. GCC on AIX does not support encoding visibility into XCOFF and the default behaviour of the IBM xlclang/xlclang++ compiler on AIX is to not encode visibility into XCOFF. That there will be future complementary changes does not seem to be a practical reason for leaving Clang gratuitously different on AIX from other AIX compilers.
>
>
> If clang did not implement this feature, symbols marked visibility("hidden") or visibility("protected") will actually be marked hidden/protected in the output on AIX. If clang does implement this feature, such symbols will instead be marked as exported default-visibility. There is no change for symbols marked visibility("default").
>
> So, the request here is that Clang on AIX should ignore the attempt to hide symbols, resulting in symbols being exported, even though the code thought it was hiding them? That's the desired behavior change?
>
> I remain unclear as to how that is a useful or important feature. Are you worried about compatibility with code which incorrectly specified visibility("hidden"), when it actually did need to export the symbol?

The same feeling here... Aren't most
__attribute__((visibility("hidden"))) guarded by macros? AIX can turn
off the macros...
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: add new option -fnovisibility for clang

Hollman, Daisy Sophia via cfe-dev
> What is ultimately the behavior for "unspecified" symbols, when no export-list is provided by the user?

If symbols have `unspecified` visibility, and no export list is provided, symbols will not get exported.

> Are you saying that on the existing AIX compilers/linkers, the export-list cannot be used to make a symbol "hidden" (non-exported), if it had been explicitly annotated visibility("default") in the source (assuming visibility declarations weren't being ignored)? That only "unspecified" symbols can be modified by the export-list?

The export list is able to override the visibility settings in the object file in some situations, but not in all situations. The scenario you described above could be overridden by export list. 
There is a comprehensive list for all scenarios here: https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html in Table 1.

Again, this is more for getting the default right on AIX. GCC and xlclang on AIX have the consistent default behavior as what we described for -mignore-xcoff-visibility. 

On Tue, Sep 15, 2020 at 5:20 PM James Y Knight <[hidden email]> wrote:
On Tue, Sep 15, 2020 at 3:29 PM Jason Liu via cfe-dev <[hidden email]> wrote:
> I remain unclear as to how that is a useful or important feature. Are you worried about compatibility with code which incorrectly specified visibility("hidden"), when it actually did need to export the symbol?

I guess I understand the point of confusion, so I will try to clarify it a little bit. 
It goes back to Clang does not have "unspecified" visibility mapping yet. On AIX, the baseline visibility is not "default" or export. The baseline visibility is "unspecified" when no attribute is marked on the symbol. 

What is ultimately the behavior for "unspecified" symbols, when no export-list is provided by the user?

And -mignore-xcoff-visibility means let all the symbols have "unspecified" visibility, whether or not any visibility attribute is specified on the symbol. So that user could use export list in the link step to control the visibility on AIX, which gives a more fine-grained control. 

On GNU/ELF, the export-list functionality (called version-script there) allows you to remove symbols from the list to be exported, but not add them. So, visibility("default") marks it as potentially-exported, but the version-script can override and make the symbol hidden if it wants to.

Are you saying that on the existing AIX compilers/linkers, the export-list cannot be used to make a symbol "hidden" (non-exported), if it had been explicitly annotated visibility("default") in the source (assuming visibility declarations weren't being ignored)? That only "unspecified" symbols can be modified by the export-list?

 
As it is right now, the llc on AIX actually treats `GlobalValue::DefaultVisibility` as "unspecified" as it is the baseline visibility mode on AIX. So it is a bit messy there, and we will need to clean that up when we add "unspecified" visibility attribute to clang for AIX. But I don't think it should prevent us from making the default behavior(unspecified visibility for all symbols) right on AIX for now. 
Hope that would clean up the confusion.


On Tue, Sep 15, 2020 at 2:35 PM Fāng-ruì Sòng via cfe-dev <[hidden email]> wrote:
On Tue, Sep 15, 2020 at 11:21 AM James Y Knight via cfe-dev
<[hidden email]> wrote:
>
> On Fri, Sep 11, 2020 at 3:55 PM Hubert Tong <[hidden email]> wrote:
>>
>> On Fri, Sep 11, 2020 at 2:58 PM James Y Knight <[hidden email]> wrote:
>>>
>>> On Thu, Sep 10, 2020 at 10:30 PM Hubert Tong <[hidden email]> wrote:
>>>>
>>>> On Thu, Sep 10, 2020 at 9:07 PM James Y Knight <[hidden email]> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 10, 2020, 6:57 PM Hubert Tong <[hidden email]> wrote:
>>>>>>
>>>>>> On Thu, Sep 10, 2020 at 6:30 PM James Y Knight via cfe-dev <[hidden email]> wrote:
>>>>>>>
>>>>>>> But why does AIX want to ignore visibility restrictions encoded via attribute? Especially by default?
>>>>>>
>>>>>> One reason is that AIX performs more early/less lazy symbol resolution (even with runtime linking) than, say, Linux. So, if a project goes with an export-by-default model (via attribute in some scope), they can cause link-time errors from symbol references to undefined symbols from code that would otherwise have been discarded as unreferenced by the linker. It seems such code is not uncommon (and has the questionable effect of exporting template instantiations based on "client provided" types that are not part of the "library"/"utility" code in question).
>>>>>
>>>>>
>>>>> But, the default visibility is "default" -- which is the most export-y visibility setting there is. So, without specifying visibility options on the command line, the only thing you can do with visibility attributes in code is to remove exports, not add additional ones.
>>>>>
>>>>> What am I missing?
>>>>
>>>> That AIX is not an ELF platform. AIX has a default visibility for XCOFF called "unspecified". This is because the ELF-based visibility options do not quite match the base case on AIX. That the most export-y visibility is named "default" at the source level is an ELF-ism.
>>>
>>>
>>> But Clang doesn't have an "unspecified" visibility, only default, protected, and hidden. And this proposal doesn't propose to add one, either. So I don't see how this command-line option makes sense in Clang, right now.
>>
>> It makes sense for Clang on AIX if it improves the consistency of behaviour with other compilers on that platform. GCC on AIX does not support encoding visibility into XCOFF and the default behaviour of the IBM xlclang/xlclang++ compiler on AIX is to not encode visibility into XCOFF. That there will be future complementary changes does not seem to be a practical reason for leaving Clang gratuitously different on AIX from other AIX compilers.
>
>
> If clang did not implement this feature, symbols marked visibility("hidden") or visibility("protected") will actually be marked hidden/protected in the output on AIX. If clang does implement this feature, such symbols will instead be marked as exported default-visibility. There is no change for symbols marked visibility("default").
>
> So, the request here is that Clang on AIX should ignore the attempt to hide symbols, resulting in symbols being exported, even though the code thought it was hiding them? That's the desired behavior change?
>
> I remain unclear as to how that is a useful or important feature. Are you worried about compatibility with code which incorrectly specified visibility("hidden"), when it actually did need to export the symbol?

The same feeling here... Aren't most
__attribute__((visibility("hidden"))) guarded by macros? AIX can turn
off the macros...
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: add new option -fnovisibility for clang

Hollman, Daisy Sophia via cfe-dev
On 2020-09-15, Jason Liu wrote:

>> What is ultimately the behavior for "unspecified" symbols, when no
>export-list is provided by the user?
>
>If symbols have `unspecified` visibility, and no export list is provided,
>symbols will not get exported.
>
>> Are you saying that on the existing AIX compilers/linkers, the
>export-list cannot be used to make a symbol "hidden" (non-exported), if it
>had been explicitly annotated visibility("default") in the source (assuming
>visibility declarations weren't being ignored)? That only "unspecified"
>symbols can be modified by the export-list?
>
>The export list is able to override the visibility settings in the object
>file in some situations, but not in all situations. The scenario you
>described above could be overridden by export list.
>There is a comprehensive list for all scenarios here:
>https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html
>in
>Table 1.
>
>Again, this is more for getting the default right on AIX. GCC and xlclang
>on AIX have the consistent default behavior as what we described for
>-mignore-xcoff-visibility.

Hi Jason, am I right for the following points?

The AIX/XCOFF visibility properties are roughly:

   SYM_V_UNSPECIFIED has no corresponding visibility bit on ELF
   SYM_V_INTERNAL ~= STV_INTERNAL
   SYM_V_HIDDEN   ~= STV_INTERNAL
   SYM_V_PROTECTED ~= STV_PROTECTED
   SYM_V_EXPORTED  ~= STV_DEFAULT

If a symbol is marked __attribute__((visibility("default"))) in the
source code, it will get the SYM_V_EXPORTED bit and cannot be restricted
by an exportlist (like a GNU version script).

The main purpose of -fnovisibility is to ignore __attribute__((visibility("default"))),
so that such a symbol can still be restricted by an exportlist.

>On Tue, Sep 15, 2020 at 5:20 PM James Y Knight <[hidden email]> wrote:
>
>> On Tue, Sep 15, 2020 at 3:29 PM Jason Liu via cfe-dev <
>> [hidden email]> wrote:
>>
>>> > I remain unclear as to how that is a useful or important feature. Are
>>> you worried about compatibility with code which incorrectly specified
>>> visibility("hidden"), when it actually did need to export the symbol?
>>>
>>> I guess I understand the point of confusion, so I will try to clarify it
>>> a little bit.
>>> It goes back to Clang does not have "unspecified" visibility mapping yet.
>>> On AIX, the baseline visibility is not "default" or export. The baseline
>>> visibility is "unspecified" when no attribute is marked on the symbol.
>>>
>>
>> What is ultimately the behavior for "unspecified" symbols, when no
>> export-list is provided by the user?
>>
>> And -mignore-xcoff-visibility means let all the symbols have "unspecified"
>>> visibility, whether or not any visibility attribute is specified on the
>>> symbol. So that user could use export list in the link step to control the
>>> visibility on AIX, which gives a more fine-grained control.
>>>
>>
>> On GNU/ELF, the export-list functionality (called version-script there)
>> allows you to remove symbols from the list to be exported, but not add
>> them. So, visibility("default") marks it as potentially-exported, but the
>> version-script can override and make the symbol hidden if it wants to.
>>
>> Are you saying that on the existing AIX compilers/linkers, the export-list
>> cannot be used to make a symbol "hidden" (non-exported), if it had been
>> explicitly annotated visibility("default") in the source (assuming
>> visibility declarations weren't being ignored)? That only "unspecified"
>> symbols can be modified by the export-list?
>>
>>
>>
>>> As it is right now, the llc on AIX actually treats
>>> `GlobalValue::DefaultVisibility` as "unspecified" as it is the baseline
>>> visibility mode on AIX. So it is a bit messy there, and we will need to
>>> clean that up when we add "unspecified" visibility attribute to clang for
>>> AIX. But I don't think it should prevent us from making the default
>>> behavior(unspecified visibility for all symbols) right on AIX for now.
>>> Hope that would clean up the confusion.
>>>
>>>
>>> On Tue, Sep 15, 2020 at 2:35 PM Fāng-ruì Sòng via cfe-dev <
>>> [hidden email]> wrote:
>>>
>>>> On Tue, Sep 15, 2020 at 11:21 AM James Y Knight via cfe-dev
>>>> <[hidden email]> wrote:
>>>> >
>>>> > On Fri, Sep 11, 2020 at 3:55 PM Hubert Tong <
>>>> [hidden email]> wrote:
>>>> >>
>>>> >> On Fri, Sep 11, 2020 at 2:58 PM James Y Knight <[hidden email]>
>>>> wrote:
>>>> >>>
>>>> >>> On Thu, Sep 10, 2020 at 10:30 PM Hubert Tong <
>>>> [hidden email]> wrote:
>>>> >>>>
>>>> >>>> On Thu, Sep 10, 2020 at 9:07 PM James Y Knight <[hidden email]>
>>>> wrote:
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> On Thu, Sep 10, 2020, 6:57 PM Hubert Tong <
>>>> [hidden email]> wrote:
>>>> >>>>>>
>>>> >>>>>> On Thu, Sep 10, 2020 at 6:30 PM James Y Knight via cfe-dev <
>>>> [hidden email]> wrote:
>>>> >>>>>>>
>>>> >>>>>>> But why does AIX want to ignore visibility restrictions encoded
>>>> via attribute? Especially by default?
>>>> >>>>>>
>>>> >>>>>> One reason is that AIX performs more early/less lazy symbol
>>>> resolution (even with runtime linking) than, say, Linux. So, if a project
>>>> goes with an export-by-default model (via attribute in some scope), they
>>>> can cause link-time errors from symbol references to undefined symbols from
>>>> code that would otherwise have been discarded as unreferenced by the
>>>> linker. It seems such code is not uncommon (and has the questionable effect
>>>> of exporting template instantiations based on "client provided" types that
>>>> are not part of the "library"/"utility" code in question).
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> But, the default visibility is "default" -- which is the most
>>>> export-y visibility setting there is. So, without specifying visibility
>>>> options on the command line, the only thing you can do with visibility
>>>> attributes in code is to remove exports, not add additional ones.
>>>> >>>>>
>>>> >>>>> What am I missing?
>>>> >>>>
>>>> >>>> That AIX is not an ELF platform. AIX has a default visibility for
>>>> XCOFF called "unspecified". This is because the ELF-based visibility
>>>> options do not quite match the base case on AIX. That the most export-y
>>>> visibility is named "default" at the source level is an ELF-ism.
>>>> >>>
>>>> >>>
>>>> >>> But Clang doesn't have an "unspecified" visibility, only default,
>>>> protected, and hidden. And this proposal doesn't propose to add one,
>>>> either. So I don't see how this command-line option makes sense in Clang,
>>>> right now.
>>>> >>
>>>> >> It makes sense for Clang on AIX if it improves the consistency of
>>>> behaviour with other compilers on that platform. GCC on AIX does not
>>>> support encoding visibility into XCOFF and the default behaviour of the IBM
>>>> xlclang/xlclang++ compiler on AIX is to not encode visibility into XCOFF.
>>>> That there will be future complementary changes does not seem to be a
>>>> practical reason for leaving Clang gratuitously different on AIX from other
>>>> AIX compilers.
>>>> >
>>>> >
>>>> > If clang did not implement this feature, symbols marked
>>>> visibility("hidden") or visibility("protected") will actually be marked
>>>> hidden/protected in the output on AIX. If clang does implement this
>>>> feature, such symbols will instead be marked as exported
>>>> default-visibility. There is no change for symbols marked
>>>> visibility("default").
>>>> >
>>>> > So, the request here is that Clang on AIX should ignore the attempt to
>>>> hide symbols, resulting in symbols being exported, even though the code
>>>> thought it was hiding them? That's the desired behavior change?
>>>> >
>>>> > I remain unclear as to how that is a useful or important feature. Are
>>>> you worried about compatibility with code which incorrectly specified
>>>> visibility("hidden"), when it actually did need to export the symbol?
>>>>
>>>> The same feeling here... Aren't most
>>>> __attribute__((visibility("hidden"))) guarded by macros? AIX can turn
>>>> off the macros...
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> [hidden email]
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> [hidden email]
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: add new option -fnovisibility for clang

Hollman, Daisy Sophia via cfe-dev
    SYM_V_UNSPECIFIED has no corresponding visibility bit on ELF
    SYM_V_INTERNAL ~= STV_INTERNAL
    SYM_V_HIDDEN   ~= STV_INTERNAL
    SYM_V_PROTECTED ~= STV_PROTECTED
    SYM_V_EXPORTED  ~= STV_DEFAULT

These mappings are mostly right.

If a symbol is marked __attribute__((visibility("default"))) in the
source code, it will get the SYM_V_EXPORTED bit and cannot be restricted
by an exportlist (like a GNU version script).
Exportlist could still override them in some scenarios. But in some cases, it could result in errors reported by the linker.
The mixed use of export list and visibility attribute could bring confusion in code development, and therefore is generally not recommended.

The main purpose of -fnovisibility is to ignore __attribute__((visibility("default"))),
so that such a symbol can still be restricted by an exportlist.
 The main purpose of the option is to get the default behavior to be consistent with other compilers on AIX (xlclang and gcc), 
which is no visibility is set on the symbol even when attribute is presented. 
Users could use the export list to control the symbol visibility. If no export list is present, no symbol is exported.

On Tue, Sep 15, 2020 at 6:42 PM Fāng-ruì Sòng <[hidden email]> wrote:
On 2020-09-15, Jason Liu wrote:
>> What is ultimately the behavior for "unspecified" symbols, when no
>export-list is provided by the user?
>
>If symbols have `unspecified` visibility, and no export list is provided,
>symbols will not get exported.
>
>> Are you saying that on the existing AIX compilers/linkers, the
>export-list cannot be used to make a symbol "hidden" (non-exported), if it
>had been explicitly annotated visibility("default") in the source (assuming
>visibility declarations weren't being ignored)? That only "unspecified"
>symbols can be modified by the export-list?
>
>The export list is able to override the visibility settings in the object
>file in some situations, but not in all situations. The scenario you
>described above could be overridden by export list.
>There is a comprehensive list for all scenarios here:
>https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html
>in
>Table 1.
>
>Again, this is more for getting the default right on AIX. GCC and xlclang
>on AIX have the consistent default behavior as what we described for
>-mignore-xcoff-visibility.

Hi Jason, am I right for the following points?

The AIX/XCOFF visibility properties are roughly:

   SYM_V_UNSPECIFIED has no corresponding visibility bit on ELF
   SYM_V_INTERNAL ~= STV_INTERNAL
   SYM_V_HIDDEN   ~= STV_INTERNAL
   SYM_V_PROTECTED ~= STV_PROTECTED
   SYM_V_EXPORTED  ~= STV_DEFAULT

If a symbol is marked __attribute__((visibility("default"))) in the
source code, it will get the SYM_V_EXPORTED bit and cannot be restricted
by an exportlist (like a GNU version script).

The main purpose of -fnovisibility is to ignore __attribute__((visibility("default"))),
so that such a symbol can still be restricted by an exportlist.

>On Tue, Sep 15, 2020 at 5:20 PM James Y Knight <[hidden email]> wrote:
>
>> On Tue, Sep 15, 2020 at 3:29 PM Jason Liu via cfe-dev <
>> [hidden email]> wrote:
>>
>>> > I remain unclear as to how that is a useful or important feature. Are
>>> you worried about compatibility with code which incorrectly specified
>>> visibility("hidden"), when it actually did need to export the symbol?
>>>
>>> I guess I understand the point of confusion, so I will try to clarify it
>>> a little bit.
>>> It goes back to Clang does not have "unspecified" visibility mapping yet.
>>> On AIX, the baseline visibility is not "default" or export. The baseline
>>> visibility is "unspecified" when no attribute is marked on the symbol.
>>>
>>
>> What is ultimately the behavior for "unspecified" symbols, when no
>> export-list is provided by the user?
>>
>> And -mignore-xcoff-visibility means let all the symbols have "unspecified"
>>> visibility, whether or not any visibility attribute is specified on the
>>> symbol. So that user could use export list in the link step to control the
>>> visibility on AIX, which gives a more fine-grained control.
>>>
>>
>> On GNU/ELF, the export-list functionality (called version-script there)
>> allows you to remove symbols from the list to be exported, but not add
>> them. So, visibility("default") marks it as potentially-exported, but the
>> version-script can override and make the symbol hidden if it wants to.
>>
>> Are you saying that on the existing AIX compilers/linkers, the export-list
>> cannot be used to make a symbol "hidden" (non-exported), if it had been
>> explicitly annotated visibility("default") in the source (assuming
>> visibility declarations weren't being ignored)? That only "unspecified"
>> symbols can be modified by the export-list?
>>
>>
>>
>>> As it is right now, the llc on AIX actually treats
>>> `GlobalValue::DefaultVisibility` as "unspecified" as it is the baseline
>>> visibility mode on AIX. So it is a bit messy there, and we will need to
>>> clean that up when we add "unspecified" visibility attribute to clang for
>>> AIX. But I don't think it should prevent us from making the default
>>> behavior(unspecified visibility for all symbols) right on AIX for now.
>>> Hope that would clean up the confusion.
>>>
>>>
>>> On Tue, Sep 15, 2020 at 2:35 PM Fāng-ruì Sòng via cfe-dev <
>>> [hidden email]> wrote:
>>>
>>>> On Tue, Sep 15, 2020 at 11:21 AM James Y Knight via cfe-dev
>>>> <[hidden email]> wrote:
>>>> >
>>>> > On Fri, Sep 11, 2020 at 3:55 PM Hubert Tong <
>>>> [hidden email]> wrote:
>>>> >>
>>>> >> On Fri, Sep 11, 2020 at 2:58 PM James Y Knight <[hidden email]>
>>>> wrote:
>>>> >>>
>>>> >>> On Thu, Sep 10, 2020 at 10:30 PM Hubert Tong <
>>>> [hidden email]> wrote:
>>>> >>>>
>>>> >>>> On Thu, Sep 10, 2020 at 9:07 PM James Y Knight <[hidden email]>
>>>> wrote:
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> On Thu, Sep 10, 2020, 6:57 PM Hubert Tong <
>>>> [hidden email]> wrote:
>>>> >>>>>>
>>>> >>>>>> On Thu, Sep 10, 2020 at 6:30 PM James Y Knight via cfe-dev <
>>>> [hidden email]> wrote:
>>>> >>>>>>>
>>>> >>>>>>> But why does AIX want to ignore visibility restrictions encoded
>>>> via attribute? Especially by default?
>>>> >>>>>>
>>>> >>>>>> One reason is that AIX performs more early/less lazy symbol
>>>> resolution (even with runtime linking) than, say, Linux. So, if a project
>>>> goes with an export-by-default model (via attribute in some scope), they
>>>> can cause link-time errors from symbol references to undefined symbols from
>>>> code that would otherwise have been discarded as unreferenced by the
>>>> linker. It seems such code is not uncommon (and has the questionable effect
>>>> of exporting template instantiations based on "client provided" types that
>>>> are not part of the "library"/"utility" code in question).
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> But, the default visibility is "default" -- which is the most
>>>> export-y visibility setting there is. So, without specifying visibility
>>>> options on the command line, the only thing you can do with visibility
>>>> attributes in code is to remove exports, not add additional ones.
>>>> >>>>>
>>>> >>>>> What am I missing?
>>>> >>>>
>>>> >>>> That AIX is not an ELF platform. AIX has a default visibility for
>>>> XCOFF called "unspecified". This is because the ELF-based visibility
>>>> options do not quite match the base case on AIX. That the most export-y
>>>> visibility is named "default" at the source level is an ELF-ism.
>>>> >>>
>>>> >>>
>>>> >>> But Clang doesn't have an "unspecified" visibility, only default,
>>>> protected, and hidden. And this proposal doesn't propose to add one,
>>>> either. So I don't see how this command-line option makes sense in Clang,
>>>> right now.
>>>> >>
>>>> >> It makes sense for Clang on AIX if it improves the consistency of
>>>> behaviour with other compilers on that platform. GCC on AIX does not
>>>> support encoding visibility into XCOFF and the default behaviour of the IBM
>>>> xlclang/xlclang++ compiler on AIX is to not encode visibility into XCOFF.
>>>> That there will be future complementary changes does not seem to be a
>>>> practical reason for leaving Clang gratuitously different on AIX from other
>>>> AIX compilers.
>>>> >
>>>> >
>>>> > If clang did not implement this feature, symbols marked
>>>> visibility("hidden") or visibility("protected") will actually be marked
>>>> hidden/protected in the output on AIX. If clang does implement this
>>>> feature, such symbols will instead be marked as exported
>>>> default-visibility. There is no change for symbols marked
>>>> visibility("default").
>>>> >
>>>> > So, the request here is that Clang on AIX should ignore the attempt to
>>>> hide symbols, resulting in symbols being exported, even though the code
>>>> thought it was hiding them? That's the desired behavior change?
>>>> >
>>>> > I remain unclear as to how that is a useful or important feature. Are
>>>> you worried about compatibility with code which incorrectly specified
>>>> visibility("hidden"), when it actually did need to export the symbol?
>>>>
>>>> The same feeling here... Aren't most
>>>> __attribute__((visibility("hidden"))) guarded by macros? AIX can turn
>>>> off the macros...
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> [hidden email]
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> [hidden email]
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev