This is the mail archive of the
mailing list for the libstdc++ project.
Re: [v3] Provide Solaris 2 libstdc++ baseline files
On Wed, 29 Sep 2010 14:53:45 +0200
> > 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)?
This mangling difference seems odd to me. Do you have a small
reproducer? This should probably be put into bugzilla and examined in
> > * 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.
Yeah. Why are they missing from the current readelf list on linux?
> 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.
The baseline_symbols files are regenerated for certain major releases.
These are just resetting the files to add in the new symbols, taking
care to make sure that no symbols disappear in the process. The last
time this was done was roughly in line with gcc-4.4.0:
2009-04-02 Jakub Jelinek <firstname.lastname@example.org>
Certainly these files could be/should be uplifted/regenerated for 4.5.0,
and so on for major releases in a less ad-hoc manner.
I confess I don't much see the point of doing it for minor releases (ie
4.5.1 to 4.5.0). Can you elaborate on this?
Also, what do you think about adding a prerequisite section to
that explains what is expected for GNU and now Solaris systems to be
versioned? I think this would be very helpful.