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: [RFC] make check-abi


>> >    From Loren's comments, it looks
>> >    like 3.2.0 baselines will be necessary for every unique target that
>> >    attempts to do abi checking. If that's the case, might as well do
>> >    object size checking by default anyway.

> config/abi it is.

Yes, upon further consideration (I posted a while ago that I had an
idea to avoid the file multiplication), I'd now agree that it is
better to have a baseline for a platform triple.  People that care
about a stable C++ library ABI on a platform may submit the 3.2
baseline.  It should be hand-checked verses other known platforms at
submission time (as you requested the details from me; I now see I
should have just blasted you 3.2_symbols-2.txt without comment; but I
will just check it in once the framework is in place ;-).

The problem with algorithmically producing the baseline based on a
template (what I had in mind when I wrote that it should be possible
to avoid per-platform files), is that the baseline is no longer just a
direct copy of a produced file.  That violates baselining 101: Never
put a human in the process when it may be avoided; we make too many
errors. ;-)

More importantly, I mistakeningly thought that we could key off, e.g.,
_GLIBCPP_USE_WCHAR_T, sizeof(this), typeof(that) and the like to
determine some parameters for expanding the baseline from a template.
However, it is possible that someone could change that setting and the
ABI checker should detect it.  Thus, we still would have needed a
per-platform set of template expansion keys.

>> > 3) should system() be used instead of automake-direct-quoting insanity?

>> That's my vote.  There are going to be problems eventually either way
>> (requiring GNU binutils), so whether we make the call from compiled code
>> or from scripts makes no difference.

> Ok. Well, this would take care of the other Makefile issues, namely make
> check-abi being unconditional at the moment. Then the
> testsuite/Makefile.am dependiencies could get removed.

> Building abi_check.cc always isn't a big deal to me. Sound ok?

Sounds good to me for reasons cited by Phil and the fact that it
should always build.


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