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: ABI regression tester, version 0.0.0pre2.alpha7


> [....] If the diff is nonzero then we have problems.
> (I need to make the diff output more readable, but normally there should
> be none at all.)

Right. That's why I started formalizing the ABI rules in abi_check.cc.

There's got to be sane output or else g++ hackers and gcc hackers won't
use it, and the automated regression checkers will just get confused.
Diff wasn't doing it for me, especially when there is a lot that can
change between lines of the script output.

There are still things that need to be done (right now version strings
are just tested for equality, when in the future things like CXXABI_1.3
should be compatible with CXXABI_1.2, etc.) That's pretty easy to add too.

There is a lot more info being collected than is being displayed. For
instance, all the symbols are being demangled. If we felt like it, we
could say, report errors if symbols in libstdc++ cannot be demangled. 

> The .so swap should be another kind of test, but I haven't automated
> that one.

I have no idea how to do this.

> > 1) build abi-checker app
> > 2) generate current list of exported symbols from libstdc++.so
> > 3) run abi-checker app against known baseline and test list, report issues
> > 
> > Thoughts? This should allow people on x86/linux to verify changes don't
> > mess with the "stable" 3.2.0 libstdc++ abi.
> 
> You've preempted the "thoughts I was going to post on putting this into
> the testsuite."  Great minds...

Great. Good to see we are on the same page.

> The two .sh scripts in your tarball are only different in that one reads
> libstdc++.so.5.0.0, and the other reads .5.0.1.  Since we use symlinks
> in the build/install directory, you could just read libstdc++.so, or
> libstdc++.so.5, and need to only maintain a single script.

Right. Sleepy. Lazy. Also, abi_check.cc has hard-wired string literals
for baseline_file and test_file, so that should be passed in argv
stylee.

(This is partly why I did the so version update yesterday, FYI. Less
confusing.)

The script could be generalized but I wanted to make sure I wasn't off
in the weeds hacking away. Thanks for your feedback.

> > 1) as written, sizes of exported object are for x86/linux and may not be
> > portable to other oses and cpu's... I'm hoping I can get somebody like
> > Loren (please) to test on xd86/BSD to see how far off I am. This isn't a
> > super big deal to me, because all I was really trying to check was the
> > list of exported symbols, which should remain constant across cpus (?).
> 
> I think this is right.

Any x86/bsd testers out there?

Perhaps we should concentrate on getting this checked in so that
interested people only have to do the 'make check-abi' bits.

> > It's easy to change what is being compared, so comparing sizes of
> > objects can be turned off.
> 
> If we start tracking more numbers, probably a "--with-cpu-specific-stuff"
> flag should go into that script.  Or "--only--portable," etc.

Yeah. For the first cut let's not deal with this complexity.

> > 2) testsuite integration
> > (util subdir? makefile work? checking for all the readelf deps? anyway......) 
> 
> The baseline files could go into config.  We have a system in place now to
> make decisions based on cpu/os combinations; we could take advantage of that.

Hmm. Perhaps. This is a good idea, I hadn't thought of this.

Do you have any ideas on how to work through the testsuite/Makefile.am
issues? Gak!!! I'm hoping to have something in yesterday, or at least
before a lot of the pending C++ linkage patches go in...


> > 3) doesn't test vtable or object layout, or alignment issues. It would
> > be possible to add at some later date, but the formalization of the abi
> > checking has to start somewhere. 
> 
> Yeah, this is giving me fits.  I'd /really/ like some decent BFD
> documentation; with that we could take apart the binary ourselves.

Supposedly the LSB "C" library testsuite has some crazy way of checking
for object layout and offsets of data members for basic types.

Be prepared for bigger hash tables.... I think it's important to
well-structure the analysis program so that this kind of stuff can be added...

>> I'm still not exactly sure I'm getting all the exported
>> symbols but I think this is really close.
> The difference between the output of your script, and simply readelf'ing
> the entire thing, should point out what we're missing.

Yeah. That's what I'm doing. (that's when I realized a specialized tool
was needed --;) ). I think things are pretty good now, actually.

-benjamin


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