From: Michael Snyder <msnyder@vmware.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>,
Jakob Engblom <jakob@virtutech.com>
Subject: Re: gdb reverse execution: how to actually run tests for it?
Date: Mon, 17 Aug 2009 18:24:00 -0000 [thread overview]
Message-ID: <4A899E2E.6080203@vmware.com> (raw)
In-Reply-To: <200908171251.07179.pedro@codesourcery.com>
Hello Jakob -- welcome back!
Pedro's reply below includes answers to most of your questions.
This is some background.
It is normal for those of us doing development on new or
unusual platforms to need to define a "board description file",
to let Dejagnu know how to do certain things with our target.
See "site.exp" in Pedro's email.
For the reverse debugging tests, I used this guard variable
to make sure the tests would only run on targets that were
explicitly tagged as being reverse-capable:
if ![target_info exists gdb,can_reverse] {
return
}
So you will want to have this in your board description file:
set_board_info gdb,can_reverse 1
Secondly, there are a few commands that are specific to
"process record", so I guarded them with this variable:
if [target_info exists gdb,use_precord] {
# Activate process record/replay
gdb_test "record" "" "Turn on process record"
}
You won't want to use those commands, so you will
not define that variable in your board description.
If there are any commands that are unique to your
implementation, you can define your own guard variable
and add them to the tests.
Thanks
Michael
Pedro Alves wrote:
> On Monday 17 August 2009 12:32:50, Jakob Engblom wrote:
>>> make check RUNTESTFLAGS="break-reverse.exp --target_board=precord" &&
>> I had to do
>>
>> make check RUNTESTFLAGS="gdb.reverse/break-reverse.exp --target_board=precord"
>>
>>
>> To make this work, after creating the precord.exp file in
>> /usr/share/dejagnu/baseboards/
>>
>
> You don't really need to clobber that directory.
>
> See:
> http://sourceware.org/gdb/wiki/TestingGDB#head-4eade7db27381c0f4747113b6edea1b8f365d73f
>
> # Create an empty file named site.exp.
> # Create a directory named boards in the same location as site.exp.
> # Create a file named native-gdbserver.exp in the boards directory (see below).
> # Set the DEJAGNU environment variable to point to the empty site.exp.
> # Run the testsuite with make check-gdb RUNTESTFLAGS="--target_board native-gdbserver".
>
> Adjust as needed, of course.
>
> Although, needing to set "gdb,use_precord" seems weird
> though. Can't we make it so that if we're testing a native
> gdb, and, if the target matches a list of targets that support
> precord, then, well, claim support for reverse, and test with precord?
> That is, get rid of the need for a board file at all unless testing
> against a remote target that supports reverse.
>
> In any case, for the cases a board file is needed for testing
> reverse, it would be nice to have that explained in the
> wiki (or somewhere else).
>
next prev parent reply other threads:[~2009-08-17 18:18 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-17 7:42 Jakob Engblom
2009-08-17 7:58 ` Hui Zhu
2009-08-17 11:33 ` Jakob Engblom
2009-08-17 11:50 ` Jakob Engblom
2009-08-17 11:55 ` Pedro Alves
2009-08-17 15:31 ` Pedro Alves
2009-08-17 15:52 ` Hui Zhu
2009-08-20 17:10 ` Pedro Alves
2009-08-19 7:34 ` Jakob Engblom
2009-08-17 18:24 ` Michael Snyder [this message]
2009-08-17 20:08 ` Jakob Engblom
2009-08-17 22:44 ` Michael Snyder
2009-08-19 7:24 ` Jakob Engblom
2009-08-19 8:58 ` Simics & reverse execution Jakob Engblom
2009-08-19 12:29 ` Hui Zhu
2009-08-19 20:03 ` Jakob Engblom
2009-08-19 20:29 ` Michael Snyder
2009-08-19 20:44 ` Daniel Jacobowitz
2009-08-19 21:09 ` Pedro Alves
2009-08-20 6:54 ` Jakob Engblom
2009-08-20 15:03 ` Pedro Alves
2009-08-27 4:44 ` Michael Snyder
2009-08-27 8:17 ` Jakob Engblom
2009-08-28 11:04 ` Michael Snyder
2009-08-28 15:17 ` Greg Law
2009-08-31 13:22 ` Jakob Engblom
2009-08-31 16:34 ` Greg Law
2009-09-01 6:37 ` Jakob Engblom
2009-09-01 13:49 ` Greg Law
2009-09-03 19:16 ` Jakob Engblom
2009-09-04 12:44 ` Greg Law
2009-09-07 7:16 ` Jakob Engblom
2009-09-07 8:13 ` Greg Law
2009-09-07 8:24 ` Jakob Engblom
2009-09-07 12:06 ` Greg Law
2009-09-08 7:21 ` Jakob Engblom
2009-09-08 12:08 ` Greg Law
2009-09-08 13:02 ` Jakob Engblom
2009-09-08 19:11 ` Greg Law
2009-09-14 8:26 ` Jakob Engblom
2009-09-17 3:07 ` Michael Snyder
2009-08-19 7:24 ` gdb reverse execution: how to actually run tests for it? Jakob Engblom
2009-08-19 15:28 ` Pedro Alves
2009-08-19 16:37 ` Tom Tromey
2009-08-20 13:10 ` Jakob Engblom
2009-08-20 14:50 ` Daniel Jacobowitz
2009-08-20 20:27 ` Michael Snyder
2009-08-20 6:53 ` Hui Zhu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A899E2E.6080203@vmware.com \
--to=msnyder@vmware.com \
--cc=gdb@sourceware.org \
--cc=jakob@virtutech.com \
--cc=pedro@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox