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 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 ru
Re: Help with integrating my test program into dejagnu
On Dec 31, 2016, at 11:18 AM, Daniel Santos wrote:
>
> The generated sources are 2MiB
Yeah, too big, better to have a generator.
> 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.
> :)
You can inform the optimizer to stop doing that. volatile is but one way.
This informs it that it doesn't get to know what is really going on.
void foo(int, float) { }
void (* volatile foo_noinfo) (int, float) = foo;
foo_noinfo (1, 3.4);
mean call foo, and inform the optimizer it doesn't get to know what is going on.
foo (1, 3.4);
means call foo, and inform the optimizer that it knows everything. This is
more complete than noinline.
>> 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.
There need be no gcc or g++ on the build system, nor the host system. The only
thing you get is a C++ compiler on the build system. It is important that the
generator program not use anything that isn't in the language standard (no gcc
extensions here). In the under test code, you can use gcc extensions, but, if
you do that, the cost is that you can't then test binary compatibility with
Microsoft's compiler (if it doesn't support the extensions you use) a la the
struct-layout-1 methodology.
Re: Help with integrating my test program into dejagnu
On 12/31/2016 02:53 PM, Mike Stump wrote:
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. :)
You can inform the optimizer to stop doing that. volatile is but one way.
This informs it that it doesn't get to know what is really going on.
void foo(int, float) { }
void (* volatile foo_noinfo) (int, float) = foo;
foo_noinfo (1, 3.4);
mean call foo, and inform the optimizer it doesn't get to know what is going on.
foo (1, 3.4);
means call foo, and inform the optimizer that it knows everything. This is
more complete than noinline.
That is interesting. That means that I can cram all of this into a
single translation unit, so I can just generate a single header instead
(I had originally started this way). Very nice! :)
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.
There need be no gcc or g++ on the build system, nor the host system. The only
thing you get is a C++ compiler on the build system. It is important that the
generator program not use anything that isn't in the language standard (no gcc
extensions here). In the under test code, you can use gcc extensions, but, if
you do that, the cost is that you can't then test binary compatibility with
Microsoft's compiler (if it doesn't support the extensions you use) a la the
struct-layout-1 methodology.
Well I'm learning all sorts of new things; I wasn't aware that the
testsuite was designed to run with other compilers! Does the Microsoft
compiler support building functions using the System V ABI? I had
presumed that they would just never do such a thing because it would
make it would easier to use FOSS on Windows, which is just
anti-monopolistic. Anyway, the test name "msabi" may be misleading;
it's goal is to test 64-bit Microsoft ABI functions that call System V
functions. So for the test to be meaningful, I would still need to be
able to at least declare a function as System V (even if I use an
assembler implementation) and for the compiler to properly call it.
I'm also testing gcc's force_align_arg_pointer attribute in this
program, and calling such ms_abi functions both normally and with an
intentionally mis-aligned stack using inline asm -- that test would
probably be useless on msvc. So I guess I will have to investigate to
find out if it's even possible to build this test on msvc. I suppose
one advantage of having part of the code generated is that some of the
tests can be skipped by just passing a parameter to the generator. I
made a bitmask for each test variation, so just passing -m 0x7b would
prevent generation of forced re-alignment tests.
Daniel
Re: Help with integrating my test program into dejagnu
On Dec 31, 2016, at 2:13 PM, Daniel Santos wrote: > > Well I'm learning all sorts of new things; I wasn't aware that the testsuite > was designed to run with other compilers! Does the Microsoft compiler > support building functions using the System V ABI? IDK. I kinda doubt it.
