This is the mail archive of the gdb-testers@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.

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

testsuite w/ SVR4-ish corefile names was: 4.17.86 on Unixware 7.0.1

>    As an aside, I see the testsuite complaining that it can't find the 
>    corefiles.   Unixware has long named core dumps as 'core.<pid>' where
>    <pid> is the PID of the dumping process.   Is there support for this
>    in the harness that I need to "turn on"?
> 
> I have a vague memory of this having been done at one time, but I just
> looked at gdb.base/corefile.exp and didn't see anything plausible.
> There's a loop near the top of corefile.exp that tries several corefile
> name possibilities, this seems worthy of tweaking:
> 
> 	foreach i "${objdir}/${subdir}/core ${objdir}/${subdir}/core.coremaker.c ${binfile}.core" {


This isn't in the form of a patch becuase it feels wrong.   Guidance welcome.

I modified dejagnu's remote.exp::local_exec to add the second line below:

	proc local_exec { commandline inp outp timeout } {
		global pid

I then uncommented the line that actually *made* the core dump and
added the name of the corefile including the pid to the above loop:

      remote_exec host "${binfile}"
foreach i "${objdir}/${subdir}/core ${objdir}/${subdir}/core.coremaker.c ${binfi
le}.core ${objdir}/core.${pid}" {


With that change, I get better results:

 make check RUNTESTFLAGS="corefile.exp"


Running ../../../gdb-4.17.86/gdb/testsuite/gdb.base/corefile.exp ...
FAIL: gdb.base/corefile.exp: print func2::coremaker_local
FAIL: gdb.base/corefile.exp: backtrace in corefile.exp

                === gdb Summary ===

# of expected passes            9
# of unexpected failures        2
# of expected failures          1
/home3/gdb/guess/gdb/testsuite/../../gdb/gdb version  4.17.86 -nx