Re: [Patch, libgfortran] PR 27740 Versioned symbols, bump so version

[Janne Blomqvist <jblomqvi at cc dot hut dot fi>]

On Tue, May 23, 2006 at 10:27:06AM -0700, Steve Kargl wrote:
> On Tue, May 23, 2006 at 06:51:46PM +0300, Janne Blomqvist wrote:
> > 
> > the attached patch bumps the so major version from 1 to 2, and
> > introduces symbol versioning for all entry points.
> > 
> > Also, since the so version is bumped, I took the liberty of removing
> > dotprod since that is always inlined in recent versions of the
> > frontend.
> > 
> > The list of symbols to version was generated from the the current
> > libgfortran.so.1.0.0, the script that I created for this purpose is
> > attached for completeness in case an eager reviewer wants to see that
> > basis for choosing symbols.
> > 
> > I also decided to version the f2c_specific and specific_ math
> > functions; is this useful or is it even counterproductive?
> > 
> > Ok for trunk?
> 
> Janne,
> 
> Can you outline the procedure for the situation where
> someone addsi/removes a function from libgfortran?  
> That is, what needs to be updated and how? 

If it's a library internal function, nothing changes from the status
quo (only the entry points are versioned and the rest are hidden from
outside view).

For adding a function foo, one can create a new version node. E.g. if
the current version node is GFORTRAN_1.0, one can do

GFORTRAN_1.1 {
    foo;
} GFORTRAN_1.0;

This means that the version node GFORTRAN_1.1 includes all of
GFORTRAN_1.0 plus foo. IMHO it doesn't make sense to make a new
version for every single new function, but say if GFORTRAN_1.0 is the
version for gcc 4.2, then all the changes for 4.3 could be bunched
into GFORTRAN_1.1 and so on.

If a function is removed the ABI is broken, so one needs to bump the
so version and start from square one.

Now, the point with ABI compatibility, and how to use versioning to
achieve it in a somewhat robust way, is that instead of modifying the
interface of function foo and hence be forced to bump the so version,
one can create a new function foo2, put it into a new version and
still keep the original function foo. Also the frontend needs to be
modified to generate code to call foo2 instead of foo. Well there are
ways to avoid adding new names, but these seem to require __asm__
directives, and it seems none of the gcc libraries use it.

The official explanation can be found in the ld manual at

http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_node/ld_25.html

Uli has some explanation of the nitty gritty details:

http://people.redhat.com/drepper/symbol-versioning

IIRC FreeBSD also has symbol versioning, but I don't know to which
extent the GNU ld versioning stuff is compatible with BSD ld. If you
want to find out, you can check out libssp on your system (my patch
copied the mechanism to detect symbol versioning ability from
libssp). On Linux you can use readelf --symbols which might be
available on FreeBSD too?

> Putting this on the wiki might be good.

Yes, I'll put the above explanation there when/if the patch is committed.

-- 
Janne Blomqvist

Attachment: pgp00000.pgp
Description: PGP signature