This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: Help with integrating my test program into dejagnu


First of all, thank you for your thoughtful response!

On 12/30/2016 06:01 PM, Mike Stump wrote:
On Dec 30, 2016, at 11:58 AM, Daniel Santos <daniel.santos@pobox.com> wrote:
Still being pretty new to GCC and having never used dejagnu, expect or Tcl, I'm trying to determine how to best integrate my test program into GCC's test harness.  I wrote this to help find breakages while working on optimizations for Microsoft 64-bit ABI pro/epilogues.  Rather than testing specific cases, it generates a few thousand unique tests by iterating through variations.  It consists of a C++ program that generates a pair of .c files (that I don't want in the same translation unit).  These are built along with a static .c and .S file and linked into the test program.  It is intended to be built and executed on the target machine and I currently run it manually with a frequently-edited Makefile.

The first thing I need help with is figuring out if this should be run by dejagnu or if I should just write a proper Makefile.in and add it to gcc's Makefile.in.  Integrating with dejagnu seems to be the most intuitive and simple, but I don't properly understand how this would affect a cross-compiler build.  Any advice?
Yeah, first step:

+GCC_BUILD_DIR       = /home/daniel/proj/sys/gcc-github/build/head
+#GCC_BUILD_DIR       = /home/daniel/proj/sys/gcc-github/build/head-test-sp-realigned
+#GCC_BUILD_DIR       = /home/daniel/proj/sys/gcc-github/build/head-test-patched
+#GCC_BUILD_DIR       = /home/daniel/proj/sys/gcc.work0/build/head
+GCC_SRC_DIR  = /home/daniel/proj/sys/gcc-github
+#GCC_SRC_DIR  = /home/daniel/proj/sys/gcc.work0

Any absolute filename is wrong, remove all.

Yes, I wouldn't have intended to submit the Makefile like this, I just sent it as it was. I should have communicated that better. I was using this to test two different patch sets.

Do:

   srcdir = .
   objdir := $(shell pwd)

in the Makefile at the top, and use use $(srcdir) to locate files in the source tree and use $(objdir) to locate files in the build tree.  You can think of . as gcc/testsuite/gcc.target/i386/msabi.  You can place any temporary files into .

Next step, add some glue code in i386.exp to run it:

Index: testsuite/gcc.target/i386/i386.exp
===================================================================
--- testsuite/gcc.target/i386/i386.exp  (revision 243984)
+++ testsuite/gcc.target/i386/i386.exp  (working copy)
@@ -418,6 +418,28 @@ if ![info exists DEFAULT_CFLAGS] then {
  dg-init
  clearcap-init
+proc run_msabi { } {
+    global srcdir subdir objdir rootme GCC_UNDER_TEST
+
+    verbose "orig srcdir is $srcdir" 0
+    verbose "orig objdir is $objdir" 0
+    verbose "orig subdir is $subdir" 0
+    verbose "GCC_UNDER_TEST is $GCC_UNDER_TEST" 0
+    if { ![isnative] } {
+       unsupported "$subdir/msabi"
+        return
+    }
+    set status [remote_exec build "make -f $srcdir/$subdir/msabi/Makefile srcdir=$srcdir/$subdir/msabi objdir=$rootme GCC_UNDER_TEST=$GCC_UNDER_TEST check"]
+    set status [lindex $status 0]
+    return $status
+}
+
+if { [run_msabi] == 1 } {
+  fail $subdir/msabi
+} else {
+  pass $subdir/msabi
+}
+
  global runtests
  # Special case compilation of vect-args.c so we don't have to
  # replicate it 16 times.

Oh, that's the magic I was looking for!

See site.exp in gcc's build directory for all the variables you can use and what values they have.  That's be a good start.  I think that would bring it up to at least a minimal level for inclusion.

 From there, I'd get rid of the rest of the Makefile, and just put the code into run_msabi.  You'll want to examine struct-layout-1(aka gcc/testsuite/gcc.dg/compat/struct-layout-1.exp), it has a recipe for running a generator program.

Being able to completely eliminate the Makefile would definitely seem ideal, especially if there's a recipe for a generator program already.

compat can also check binary compatibility between two compilers.  For that to work, one would have to run in an environment where one can run the other compiler.

Another way to simplify it would be to just check in the generated program as a .h file, and then #include all the bits in msabi.c, and then test msabi.c normally.  This is reasonable if the generated program isn't that big.  If big, then that should be avoided.

The generated sources are 2MiB with the default generation parameters. Also, I can't have the two generated .c files in the same translation unit (at least in their current form) because gcc's too smart with optimizations. :) If I call a very simple global function marked "noinline" within the same translation unit, it will get rid of the function call anyway. I suppose I could defeat that by calling it via a global pointer. So perhaps it can be further simplified now that I think more about it.

I'll punt to the x86 people on wether or not they want the tester in the tree.  Also, the .exp file can be created in the msabi directory, and dejagnu will run it from there.  You then would have no changes to i386.exp.  Seems slightly cleaner.  Once you get comfortable with it, you can remove the verbose lines.  I just put them in so that you can see those variables.

That was the original approach I was trying, I just couldn't figure out enough of the code to make an msabi.exp work, so this is a huge help!

You might need to conditionalize the test to only run on those systems that can compile and run the code, to do that you might need [istarget "triplet"], where triplet is a system where you know it will work.  I didn't check the code to see how portable it was.

Other than being x86_64-specific and making heavy use of gcc extensions, the C & C++ code is platform portable. I did manage to find my target test code examining the stackalign .exp.

if { ![istarget x86_64-*-*] } then {
  return
}

Hope that helps.  Also, see testsuite/lib/*.exp, and testsuite/.../*.exp in the source tree for hints on variables, code, coding style, and examples of all sorts of things.

This is perfect, thank you so much!

Daniel


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