Re: RFH: Symbol versions for __aeabi symbols

[Mark Mitchell <mark at codesourcery dot com>]

Paolo Carlini wrote:

> I would suggest double checking with Benjamin

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

> > 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.

OK, that makes sense.  I wasn't quite sure what the tradeoffs were. 
Obviously, there are not presently any binaries linked against these 
symbols, since they aren't exported, so exporting the symbols with any 
version cannot break existing binaries.  But, I guess that if we added 
them with an old version, then new binaries might not get a very obvious 
error when they were linked against an old libsupc++.

I'll add a CXXABI_1.3.3 version.

> > 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... I don't think we can really do that...

OK, I'll add them, test on both x86 and ARM Linux, and submit.

Thanks,

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713