This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB 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: [patch] testsuite: Make solib-corrupted.exp untested for probes [Re: [RFA 0/4 take 2] Improved linker-debugger interface]


On Thu, 23 Aug 2012 21:10:43 +0200, Pedro Alves wrote:
> On 08/18/2012 07:34 AM, Jan Kratochvil wrote:
> 
> > +# With probes interface GDB no longer scans the inferior library list so its
> > +# corruption cannot be tested.  There is no way to disable the probes
> > +# interface.
> 
> I'm really not familiar with how the test is written, but I imagine that
> gdb will still scan the library list on "attach" as usual.  Maybe the test could
> be adjusted to attach to the inferior, somehow.

OK, a good idea.  Although it should test also core files now and this is
a pending todo item of Gary.


> > +if { [llength $probes] == 0 } {
> > +    xfail $test
> 
> It doesn't look like anything failed?  Is this a left over?
> 
> > +    untested "GDB is using probes"
> > +    return
> > +}
> > +

This is intentional, I write it always this way, it is in many other testcases
in the testsuite.  We can clarify it in
	http://sourceware.org/gdb/wiki/GDBTestcaseCookbook
if you do not find it right.

There is some "complicated" test which can FAIL in various cases.  FAIL
normally never happens, it would be something to investigate.

The valid results of such test is either PASS - the testfile can continue for
the real test.  Or XFAIL because the current testing environment is not
suitable for this testfile.  Therefore it will also make the testfile
'untested'.

It could suppress "pass $test" and "xfail $test" and only keep that 'untested'
path there.  But in such case if the deciding code unexpectedly fails it will
do 'fail $test' where $test ('info probes') is normally never visible in the
results, this makes diffs of the results suspicious to me.  Also when
evaluating the gdb.log files there is some real command and results evaluation
without any PASS afterwards.

This is why I prefer 'pass $test' and 'xfail $test'+'untested "why"' in such
case.

If the conditional for 'untested' case is simple - such as [is_remote host] -
I understand there should be no pass/xfail for such case.


Thanks,
Jan


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