This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Introduce gdb_interact in testsuite
- From: Simon Marchi <simon dot marchi at ericsson dot com>
- To: Doug Evans <dje at google dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Thu, 22 Jan 2015 16:14:55 -0500
- Subject: Re: [PATCH] Introduce gdb_interact in testsuite
- Authentication-results: sourceware.org; auth=none
- References: <1421340032-30709-1-git-send-email-simon dot marchi at ericsson dot com> <CADPb22TbuWnvcWV8FfcAB0aDctW0EwbQ4HQakda6NzwJQVJaGg at mail dot gmail dot com> <54C16318 dot 7060203 at ericsson dot com>
On 15-01-22 03:52 PM, Simon Marchi wrote:
> On 15-01-20 08:42 PM, Doug Evans wrote:
>> On Thu, Jan 15, 2015 at 8:40 AM, Simon Marchi <simon.marchi@ericsson.com> wrote:
>>>
>>> gdb_interact is a small utility that we have found quite useful to debug
>>> test cases.
>>>
>>> Putting gdb_interact in a test suspends it and allows to interact with
>>> gdb to inspect whatever you want. You can then type ">>>" to resume the
>>> test execution. Of course, this is only for gdb devs. It wouldn't make
>>> sense to leave a gdb_interact permanently in a test case.
>>>
>>> When starting the interaction with the user, the script prints this
>>> banner:
>>>
>>> +------------------------------------------+
>>> | Script interrupted, you can now interact |
>>> | with by gdb. Type >>> to continue. |
>>> +------------------------------------------+
>>>
>>> Notes:
>>> * When gdb is launched, the gdb_spawn_id variable (lib/gdb.exp) is
>>> assigned -1. Given the name, I would expect it to contain the gdb
>>> expect spawn id, which is needed for interact. I changed all places
>>> that set gdb_spawn_id to -1 to set it to the actual gdb spawn id
>>> instead.
>>>
>>> * When entering the "interact" mode, the last (gdb) prompt is already
>>> eaten by expect, so it doesn't show up on the terminal. Subsequent
>>> prompts do appear though. We tried to print "(gdb)" just before the
>>> interact to replace it. However, it could be misleading if you are
>>> debugging an MI test case, it makes you think that you are typing in a
>>> CLI prompt, when in reality it's MI. In the end I decided that since
>>> the feature is for developers who know what they're doing and that one
>>> is normally consciously using gdb_interact, the script doesn't need
>>> to babysit the user.
>>>
>>> * There are probably some quirks depending on where in the script
>>> gdb_interact appears (e.g. it could interfere with following
>>> commands and make them fail), but it works for most cases. Quirks can
>>> always be fixed later.
>>>
>>> The idea and original implementation was contributed by Anders
>>> Granlund, a colleague of mine. Thanks to him.
>>>
>>> gdb/testsuite/ChangeLog:
>>>
>>> * gdb.base/statistics.exp: Assign spawn id to gdb_spawn_id.
>>> * gdb.base/valgrind-db-attach.exp: Same.
>>> * gdb.base/valgrind-infcall.exp: Same.
>>> * lib/mi-support.exp (default_mi_gdb_start): Same.
>>> * lib/prompt.exp (default_prompt_gdb_start): Same.
>>> * lib/gdb.exp (default_gdb_spawn): Same.
>>> (gdb_interact): New.
>>
>> [Apologies for the resend.]
>>
>> I'm not sure why we're assigning -1 instead of a usable value,
>> but I can't find anything to suggest assigning a real id will
>> cause problems.
>>
>> Plus given how trivial gdb_interact is, the patch is fine by me.
>>
>> Another way such things are debugged is by first running tests
>> with TRANSCRIPT=y, and then massaging the transcript.N files
>> afterwards. I'm all for adding more ways of debugging tests.
>> Thanks!
>
> Thanks, pushed.
Just a note, I added a section about this in the TestingGDB wiki page:
https://sourceware.org/gdb/wiki/TestingGDB#Interacting_with_a_test_case