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 4/4] Non-stop exec tests


Thank you for looking at this.

On 5/25/2014 8:29 PM, Doug Evans wrote:
> On Fri, May 23, 2014 at 3:49 PM, Don Breazeal <donb@codesourcery.com> wrote:
>> This patch extends the non-ldr-exc-*.exp tests so that they run all their cases in non-stop mode as well as all-stop mode.  These tests cover handling of exec events when non-leader threads call exec.
>>
>> The tests now report 'untested when 'runto_main' fails.  In non-stop mode with 'target extended-remote', runto_main always fails with something like:
>>
>> (gdb) run
>> Starting program: /home/me/gdb/testsuite/gdb.threads/non-ldr-exc-4
>> Unexpected vCont reply in non-stop mode: T0506:10e0ffffff7f0000;07:c8deffffff7f0000;10:c1a6abaaaa2a0000;thread:p5ee.5ee;core:0;
> 
> Did you try --target_board=native-extended-gdbserver ?

Yes.  To be clear, the exec events are only implemented for multiprocess
/ extended-remote.  Before posting the initial patch I tested native
GDB, --target_board=native-gdbserver, and
--target_board=native-extended-gdbserver.

> 
>> This happens in other tests as well (e.g. gdb.threads/thread_events.exp), so I copied the error handling from that test so that the non-stop tests report 'untested' for target extended-remote.  I couldn't find anything related to this in the gdb bug database, but I assume it is a known problem since the other tests handle it.
>>
>> Regards,
>> --Don
>>
>> testsuite/
>> 2014-05-22  Don Breazeal  <donb@codesourcery.com>
>>
>>         * gdb.threads/non-ldr-exc-1.exp: Add non-stop cases
>>         * gdb.threads/non-ldr-exc-2.exp: Ditto.
>>         * gdb.threads/non-ldr-exc-3.exp: Ditto.
>>         * gdb.threads/non-ldr-exc-4.exp: Ditto.
> 
> Hi.
> Still going through the patch series, but have an initial comment.
> 
> The following test at the top of each .exp file could be changed to
> something like !linux && is_remote, right?
> 
> # No exec event support in the remote protocol.
> if { [is_remote target] } then {
>     continue
> }
> 
> These tests now pass with native-gdbserver (and
> native-extended-gdbserver) so we'll want to at least run these tests
> with those, I presume.
> 
I don't expect the tests to pass with native-gdbserver, since the
implementation is only for multiprocess/extended-remote.  I should have
made that more apparent.

[Note: the rationale for restricting exec events to multiprocess was
that follow-exec-mode can allow multiple inferiors to exist, even if
they aren't running simultaneously.  Also, follow-exec-mode and
follow-fork-mode are closely related, and follow-fork-mode definitely
requires multiprocess.]

The native-extended-gdbserver tests aren't affected by the test for
remote at the top of each .exp file.  The GDB manual says that these
events (or at least fork events) are supported for native GDB on newer
versions of Linux and HP-UX, and any change I make for
native-extended-gdbserver will affect the native tests.

Given that the feature is only available with extended-remote, do you
still feel I need to change something?  I'm not sure how to restrict a
test to "Linux or HP-UX", or to newer versions of them.

Thanks
--Don



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