Re: [PATCH 3/8] Disassembly unit test: disassemble one instruction

[Pedro Alves <palves@redhat.com>]

On 01/12/2017 05:03 PM, Yao Qi wrote:
> On 17-01-12 13:06:26, Pedro Alves wrote:
>> I'd much prefer if the core of the unit testing framework doesn't learn
>> about different random subsystems.  Consider what we'd do if we
>> wanted to reuse selftest.c in gdbserver.  I think we will at some point.
> 
> Can we consider using some general c++ unit test frameworks rather than
> selftest.c?  I don't see any issues if we can merge the unit test
> results into dejagnu test result gdb.sum.

We can consider anything, of course.  But I don't know whether
that's give us any significant advantage.  I never evaluated any myself.
Do we miss something important with the current framework?  
Would it be used as an as external dependency (required? optional?), or
would we import it into the codebase?  How would it
affect the way we write tests?  And the way we write the code that ends
up tested?  Would it force something on the codebase that would be
undesirable?  Etc., etc.

> It should be straightforward to convert some c++ unit test result
> to the dejagnu style, and use dg-extract-results.sh to merge them
> into a single gdb.sum.
> 
> David proposed using gtest in gcc unit test, and the major objection
> /concern is we may have two different format of test results.
> https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00765.html but the
> concern can be addressed as I stated above.
> 
>>
>> How about we move all this gdbarch stuff elsewhere, like
>> gdb/arch-utils.c or a new gdb/arch-selftests.c?
>>
> 
> OK, I'd like to name it as gdb/selftests-arch.c, because
> arch-selftests.c looks like "a unit test case of arch".  However,
> I want this file serves as "a runner to run one test case for every
> gdbarch".

Makes sense.

Thanks,
Pedro Alves