Re: RFH: Symbol versions for __aeabi symbols

[Benjamin Kosnik <bkoz at redhat dot com>]

> Benjamin, I've explicitly added you to the CC: at Paolo's suggestion.

Sorry for the delay, just getting back up after my move.

> >> 1. What version should I use?
> >>
> >> In config/abi/pre/gnu.ver, it looks like the non-ARM variants
> >> are exported with version CXXABI_1.3.  Should I just put the ARM
> >> variants there too?  Or add them to CXXABI_1.3.2, which is the
> >> latest version? Or create a new CXXABI_1.3.3 version?
> > 
> > Yes, normally we create a new version in such cases. The only
> > situation in which we have an optionis when we are between releases
> > and recently created a new version after the release. Then we can
> > keep adding provided we know nobody is releasing from snapshots or
> > any dangerous situation like that.
> > 
> > Otherwise, seems quite obvious to me that the only safe, general
> > approach when there are already around releases with CXXABI_1.3.2,
> > is opening a new CXXABI_1.3.3 for the new symbols.

Right.

The rule of thumb is to always append new stuff (unless the latest
label is one that is not present on a release.)
 
> >> 2. Is it bad to add them unconditionally, even though the
> >> symbols are only defined on ARM platforms?  Or do I need to somehow
> >> conditionalize on being on an ARM system?  And, if so, how do I do
> >> that?
> > 
> > This seems more subtle but I cannot imagine any problem with just
> > exporting the symbols, provided of course are only defined on
> > ARM... Ah now I see the real issue: ideally we would like to stay
> > at 1.3.2 for all the other targets and bump to 1.3.3 *only* for
> > ARM... 

Right. I think it's even more subtle than that, in that it's arm only
with a particular ABI selected, no?

> I don't think we can really do that...

This has been done in the past by using port_specific_symbol_files, say
adding a

config/cpu/arm/arm-extra.ver

file with the new symbols in CXXABI_ARM_1.3.

I would suggest re-using this approach, or some close variant.

This has the advantage of being a similar approach to the one used for
the CXXABI_LDBL_1.3 exports used on some arches (powerpc/sparc/s390)
for long double changes.

best,

-benjamin