This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Benjamin Kosnik <bkoz@redhat.com> writes:

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

Seems to have been an artefact of either the old readelf-based
extract_symvers or something else.  I'll open a PR if I discover
something like this again.

>> > * 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?

Easy: in readelf --symbols --wide output, they show up with type TLS

  1920: 00000000     4 TLS     GLOBAL DEFAULT   16 _ZSt11__once_call@@GLIBCXX_3.4.11
   536: 00000004     4 TLS     GLOBAL DEFAULT   16 _ZSt15__once_callable@@GLIBCXX_3.4.11

while extract_symvers currently only handles FUNC, NOTYPE, and OBJECT.

>> 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  <jakub@redhat.com>
>
> 	* config/abi/post/powerpc64-linux-gnu/32/baseline_symbols.txt:
> 	....
>
> 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. 

That's what I'd suggest as well, and it was my plan to regenerate the
Solaris baselines shortly before 4.6.0 is released.

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

No, not really.  I'm not even sure if minor (or micro?) releases should
add new symbols at all.

> Also, what do you think about adding a prerequisite section to
> http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
>
> that explains what is expected for GNU and now Solaris systems to be
> versioned? I think this would be very helpful.

Right, seems like an excellent idea, though I've had a very hard time
fightying with DocBook (and getting some printable output).  At the
moment, the libstdc++ manual seems to be a well-kept secret: it isn't
even mentioned in Installing GCC.  I'd prefer to move some sections
relevant to the installation of libstdc++ (like the configure options
and maybe such a prerequisites section) to install.texi, though, to have
all GCC-related installation documentation in one place.

In fact, I've just checked and the Prerequisites section already exists
on that page, but doesn't give much useful information.  When I've
installed the Solaris symvers patches, I've added something to
install.texi: GNU c++filt and perl immediately come to mind.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]