[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

'make check' failure in gcc-3.3 in x86->x86 cross build. How to debug d

From: Dan Kegel
Subject: 'make check' failure in gcc-3.3 in x86->x86 cross build. How to debug dejagnu usage problems?
Date: Thu, 05 Jun 2003 19:25:32 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529

I compiled an x86->x86 cross toolchain with gcc-3.3 and glibc-2.2.5
on i686 by running the script at
(This was run on a Debian 3.0 system itself using glibc-2.2.5-14.3.
I'm developing a script to build and test x86->ppc and x86->sh toolchains,
and use the x86->x86 case to shake out changes to my script.)

I then tried running the binutils and gcc test suites more or less as follows:

$ export 
$ cd build-binutils
$ RUNTESTFLAGS="--host=i686-host_unknown-linux-gnu 
--target=i686-unknown-linux-gnu" make check

                === binutils Summary ===

# of expected passes            25
# of untested testcases         7
                === gas Summary ===

# of expected passes            58
../as-new 20030121
                === ld Summary ===

# of expected passes            29
# of untested testcases         13

(OK, the binutils suite worked fine, but:)

$ cd ../build-gcc
$ RUNTESTFLAGS="--host=i686-host_unknown-linux-gnu 
--target=i686-unknown-linux-gnu" make check

Testing 27_io/
doing compile
pid is 6196 -6196
output is
spawning command ./istream_sentry.exe
exp7 file6
Testing 27_io/
doing compile
pid is 6206 -6206
output is
spawning command ./istream_unformatted.exe
exp7 file6
close result is child killed: SIGABRT
FAIL: 27_io/ execution test
                === libstdc++-v3 Summary ===

# of expected passes            452
# of unexpected failures        1
# of unexpected successes       1
# of expected failures          27
runtest completed at Thu Jun  5 16:32:50 2003
make[4]: *** [check-DEJAGNU] Error 1

I suspected the failure was because the test was being run
with my native system, which has a slightly different runtime
library, so I checked the environment of the expect process.
$ ps augx | grep expect | egrep -v 'grep|export'
dank      7358  0.6  0.5  4344 2604 pts/0    T    17:31   0:06 expect -- 
/usr/share/dejagnu/runtest.exp ...
$ tr '\000' '\012' /proc/7358/environ | grep LD_LIBRARY_PATH

So the test harness somehow magically did set LD_LIBRARY_PATH,
but not to anything useful.  In fact, the second thing in
the path looks truncated.  Hmm.  Whose fault is that?
Grepping through the dejagnu sources, it seems the unix target
sets LD_LIBRARY_PATH, but that code isn't being invoked;
looking at the logfile left in testsuite/ shows no "Setting LD_LIBRARY_PATH..."
messages.  So it's a total mystery to me who's setting that variable.
(It's not set in runtest's environment.)
It is at this point that I start throwing rotten tomatoes at dejagnu :-)

I wonder if this could be some heinous length limit on environment
variables in some c program, but the only c program involved is
probably the tcl interpreter, and that couldn't have such a lame problem, could 

So here's the question: what's the best way to figure out dejagnu problems like 
My usual tools - find -name '*.exp', xarg, grep, a big printout, and a 
cross-reference -
aren't helping enough.
I did see when I read through the source that there is a built-in debugger.
(I imagine I could set a breakpoint on setenv, say.)
When dejagnu wizards are tracking problems down, do they use the debugger, or 

(I really, really wish the gcc testsuite was written with simpler
tools.  The complexity of dejagnu is mind-boggling.  Either that,
or I'm just getting stupid.)


Dan Kegel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]