Re: visibility attributes

[Rik]

On 02/25/2016 01:30 PM, John W. Eaton wrote:

On 02/24/2016 12:24 PM, Rik wrote:

 My guess is that the the linker symbol
table is crowded with a bunch of functions that are never called outside
of a single translation unit (static file scope). This increases the
sizes of the object files and probably makes the linker work a bit
harder to read, but never use, these definitions.

If that's true, then I think just making those functions static (if they are just plain old functions) should be sufficient.

Yes, making things static where they can be is the obvious first choice.

For member functions of a class that has a public interface, I think visibility would need to be defined for functions that are not actually needed outside of a single file.  But we currently only tag entire classes, not individual methods (if that is even possible, I haven't checked).

Yes, I think that is the savings we are looking at.  We have many classes which contain a subclass that is the actual implementation, i.e., maintains a reference count, etc.  I assume that even if the subclass is protected the I/F will be exported.

At any rate, I'm sure I don't have enough time to solve this, but I started down that path.  I posted a minimal patch to the patch tracker at https://savannah.gnu.org/patch/?8919.

The description is:

By using visibility attributes a programmer can control which functions are exported into the symbol table of a shared object.  By reducing the number of symbols the linker can run faster and the generated shared object is smaller.

For an explanation of the benefits and the approach see: https://gcc.gnu.org/wiki/Visibility.

Octave already has support mostly in place for this.

Steps:

1) make maintainer-clean
2) Apply visibility.patch from this issue report
3) change CFLAGS and CXXFLAGS to include "-fvisibility=hidden"
4) bootstrap
5) configure
6) make

The build currently fails because liboctinterp is looking for symbols that have not been exported from liboctave.  This requires finding the necessary functions and decorating them with OCTAVE_API so they are exported into the symbol table of liboctave.  This is where things stand today (2/26/2016).

--Rik