[Patches] [ python-Patches-1192789 ] Use GCC4 ELF symbol visibility

SourceForge.net noreply at sourceforge.net
Sun Aug 7 23:49:03 CEST 2005


Patches item #1192789, was opened at 2005-04-30 01:46
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1192789&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: James Henstridge (jhenstridge)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use GCC4 ELF symbol visibility

Initial Comment:
GCC4 includes some new features that make it easier to
control what symbols are exported from a library for
linking.

The attached patch makes Python use these features,
limiting the exported symbols to the public Python C
API (i.e. the same symbols as are exported under Windows).

The patch sets the ELF visibility of the public Python
APIs to "protected", which means that the symbol is
exported but internal calls to those symbols are done
as direct function calls. 

In my local tests on i386 Linux, pystone and
parrotbench run about 5% faster on a "--enable-shared"
build of Python with the patch applied.

For a non shared library build of Python, performance
is pretty much identical (I'll probably need to do some
more tests).  However it still has the benefit of not
exporting private Python API.

The patch also touches the init routines of a number of
extension modules, since they weren't marked with
PyMODINIT_FUNC, which caused them to build incorrectly
with the patch (the init function ended up being
private, so Python couldn't load the module).

I've only tested this patch against 2.4.1, but it
probably applies without too much trouble to the 2.5
development line.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2005-08-07 23:49

Message:
Logged In: YES 
user_id=21627

Doesn't this cause backwards compatibility problems with
extension modules which fail to declare their entry point
with PyMODINIT_FUNC? Such modules would stop working when
recompiled with the patch, right?

Also, shouldn't the -fvisibility argument only be used if
the __attribute__ syntax is supported?

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2005-05-10 04:47

Message:
Logged In: YES 
user_id=146903

I just tried out the patch on an AMD64 Linux machine.  There
is some improvement in the --enable-shared case, but it
doesn't seem to be as big as on i386.

I only tested pystone though, since parrotbench gives an
assertion error on this box.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1192789&group_id=5470


More information about the Patches mailing list