This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH v2] Add autoload-breakpoints [2/6] ReportAsync-test
- From: Yao Qi <yao at codesourcery dot com>
- To: Hui Zhu <hui_zhu at mentor dot com>
- Cc: <gdb-patches at sourceware dot org>
- Date: Tue, 8 May 2012 16:39:21 +0800
- Subject: Re: [PATCH v2] Add autoload-breakpoints [2/6] ReportAsync-test
- References: <4F8562B7.email@example.com> <4F9B98E2.firstname.lastname@example.org> <4F9C17CD.email@example.com> <4FA8CA98.firstname.lastname@example.org>
On 05/08/2012 03:26 PM, Hui Zhu wrote:
>> Remote feature should be tested in remote target or board file.
>> You are testing a remote feature GDB unconditionally, even in native
>> gdb. It looks incorrect to me.
> This just a check for the this small gdbserver is OK. I don't think this test will work with board or something.
My point is this test case exercises some "undesired" features w.r.t.
testsuite and config. I configure and build a native gdb, and type
`make -k check' in gdb build dir. Then, I'll examine the FAILs in
gdb.sum to see the status of native gdb, what does the FAILs, if any, in
gdb.remote/reportasync-test.exp mean to me? It sounds like "I did a
medical check-up to my eyes, but result tells me something wrong in my
ears". However, I am not strongly against this test case.
We have a sub-dir gdb.server under testsuite/, *.exp are run even when
testing native gdb, but they are test cases to GDBserver, rather than
GDB, AFAICS. When we see some FAILs in it, that means GDBserver has
something wrong, at least ideally :)