Phil Edwards - Re: ABI regression tester, version 0.0.0pre2.alpha7 (original) (raw)

This is the mail archive of the libstdc++@gcc.gnu.orgmailing 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]

On Tue, Aug 20, 2002 at 12:46:30PM -0700, Benjamin Kosnik wrote:

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.

Certainly.

Diff wasn't doing it for me, especially when there is a lot that can change between lines of the script output.

I think there would be less difference than you imagine, as long as we sort the text before diffing. I've added some text to the autocrasher, next time a variation appears it should be more human-readable.

Anyhow... multiple paths to the same solution. I'll take the low road and you take the high road, and we'll both get to scotland.

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

I have no idea how to do this.

Easy to do in my autocrasher, but darn near impossible to generalize enough for testsuite checkin.

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.

The first version of this program you posted, I took and added system() calls to do the readelf-pipe-etc stuff, so that the name of the .so could be passed in as argv. Have to assume GNU readelf, etc, so that wouldn't work.

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

Off the top of my head, we build your program(s) and then do the testing work in a script:

noinst_PROGRAMS = abicheck
abicheck_SOURCES = abicheck.cc

abi-check:
    <span class="katex"><span class="katex-mathml"><math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mo stretchy="false">(</mo><mi>S</mi><mi>H</mi><mi>E</mi><mi>L</mi><mi>L</mi><mo stretchy="false">)</mo></mrow><annotation encoding="application/x-tex">(SHELL) </annotation></semantics></math></span><span class="katex-html" aria-hidden="true"><span class="base"><span class="strut" style="height:1em;vertical-align:-0.25em;"></span><span class="mopen">(</span><span class="mord mathnormal" style="margin-right:0.05764em;">S</span><span class="mord mathnormal" style="margin-right:0.08125em;">H</span><span class="mord mathnormal" style="margin-right:0.05764em;">E</span><span class="mord mathnormal">LL</span><span class="mclose">)</span></span></span></span>(srcdir)/testsuite/run_a_sane_script $(builddir)

Pass in the build directory path, and I think the script can figure out everything else, e.g., call the $(builddir)/testsuite/abicheck, scan the $(builddir)/src/.libs/lib.so, etc.

Phil

-- I would therefore like to posit that computing's central challenge, viz. "How not to make a mess of it," has /not/ been met. - Edsger Dijkstra, 1930-2002

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