This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/4] Move trace conditions tests from ftrace.exp to trace-condition.exp
- From: Antoine Tremblay <antoine dot tremblay at ericsson dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Antoine Tremblay <antoine dot tremblay at ericsson dot com>, <gdb-patches at sourceware dot org>
- Date: Fri, 27 May 2016 08:35:27 -0400
- Subject: Re: [PATCH 1/4] Move trace conditions tests from ftrace.exp to trace-condition.exp
- Authentication-results: sourceware.org; auth=none
- References: <1463504594-4419-1-git-send-email-antoine dot tremblay at ericsson dot com> <b5a368d3-91ab-2ed2-4a73-efe792d9e88c at redhat dot com>
Pedro Alves writes:
> On 05/17/2016 06:03 PM, Antoine Tremblay wrote:
>> This patch moves conditional tests that were done in ftrace.exp to
>> trace-conditon.exp.
>
> Typo conditon.exp.
>
Fixed.
>>
>> Note that emit_ref is now tested by the anarg local variable there is no
>> need to test the register directly.
>>
>> The test coverage remains the same.
>
> How did you determine it that it's the same?
I've put an assert in each emit function and validated that they are all
called before / after the move.
>
> E.g., seems like the <, >, etc., conditions in ftrace.exp use a
> global variable, while the trace-condition.exp ones use constants.
>
That is not a problem since testing with a constant tests the < >
on it's own.
The reading of global variable used in ftrace is tested separately in
trace-condition.exp.
> I also notice that all tests in trace-condition.exp expect 10 frames
> to be collected. If a condition's handling is broken and the
> tracepoints ends up unconditional, will we ever notice?
>
That's a good point, that was pre-existing in trace-condition.exp I
think it's mitigated partially by counter-cases like:
test_tracepoints $trace_command "21 == 21" 10
test_tracepoints $trace_command "21 != 42" 10
But could be a problem with conditions like:
test_tracepoints $trace_command "(0xabababab & 0x0000ffff) == 0xabab" 10
It could add counter cases to all true/false tests like :
test_tracepoints $trace_command "(0xabababab & 0x0000ffff) == 0xffff" 0
And do that for the others.
> Seems like we have counter-cases using the same operators
> but that eval false, like (relative to your patch):
>
Yes indeed, as above. I'll do that in a patch preceding this one that
will change the existing trace-condition.exp first.
Thanks,
Antoine