Re: [v3] Provide Solaris 2 libstdc++ baseline files

[Paolo Carlini <paolo dot carlini at oracle dot com>]

Hi,
> I think there are a two open questions:
> * Do you have a suggestion for the source of the two differently mangled
>   instances of std::system_error::system_error(std::error_code) on
>   Solaris 11/x86 (but not SPARC)?
>
> * What to do with TLS symbols (std::__once_call and
>   std::__once_callable)?  When using pvs on Solaris, I cannot easily
>   exclude them from the the baseline_symbols.txt files, but it might be
>   appropriate to include them on other systems that use readelf, too,
>   since they effectively form part of the ABI.
>   
No idea, I'm sorry.
> I'm not sure to follow the reasoning here: as we mean it, a baseline,
>> by definition, *never* changes, it's sort-of a concrete surrogate of an
>> ABI which we don't want to break. Then, given the baseline, we want to
>> check that successive minor versions of the library only add symbols,
>> versioned at the corresponding minor version, and never remove symbols
>> or add symbols at previous (older) minor versions. Indeed, this is what
>> abi_check does. Thus, I'm not sure to follow your reasoning... Granted,
>> something is special here about adding the baselines *now*, because
>> normally the baselines we have correspond to the gcc3.4.0 symbols, but
>> anyway, the general rule about the correct way of moving forward without
>> breaking old executables should stay the same, in particular no changes
>> to the baselines, etc.
>>     
> I'm a bit worried about this procedure because it would allow to add a
> symbol after 3.4.0 and later remove it again without being noticed.  I'd
> expect the baselines to be regenerated just before minor releases to
> guard against exactly such a situation, of course making certain at this
> time that they are a strict superset of the previous release's baseline.
>   
Well, for sure what I described is what we have been doing for many
years, since gcc3.4.0. Maybe check_abi could be improved to deal with
the possible problem your are describing, actually has been further
tightened at least once. If you have patches about that would be
welcome, I think.

Paolo.