Introduce gdb_interact in testsuite
Commit Message
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.
---
gdb/testsuite/gdb.base/statistics.exp | 2 +-
gdb/testsuite/gdb.base/valgrind-db-attach.exp | 2 +-
gdb/testsuite/gdb.base/valgrind-infcall.exp | 2 +-
gdb/testsuite/lib/gdb.exp | 21 ++++++++++++++++++++-
gdb/testsuite/lib/mi-support.exp | 2 +-
gdb/testsuite/lib/prompt.exp | 2 +-
6 files changed, 25 insertions(+), 6 deletions(-)
Comments
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!
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.
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
@@ -24,6 +24,6 @@ if { $res < 0 || $res == "" } {
perror "Spawning $GDB failed."
return
}
-set gdb_spawn_id -1
+set gdb_spawn_id $res
gdb_test "" "Startup time: \[0-9.\]+ \\(cpu\\), \[0-9.\]+ \\(wall\\)\r\nSpace used: \[0-9.\]+ \\(\\+\[0-9.\]+ during startup\\)" "startup time and space"
gdb_exit
@@ -41,7 +41,7 @@ if { $res < 0 || $res == "" } {
}
pass $test
# Declare GDB now as running.
-set gdb_spawn_id -1
+set gdb_spawn_id $res
# GDB spawned by `valgrind --db-attach=yes' stops already after the startup is
# executed, like with non-extended gdbserver. It is also not correct to
@@ -33,7 +33,7 @@ if { $res < 0 || $res == "" } {
}
pass $test
# Declare GDB now as running.
-set gdb_spawn_id -1
+set gdb_spawn_id $res
# GDB started by vgdb stops already after the startup is executed, like with
# non-extended gdbserver. It is also not correct to run/attach the inferior.
@@ -1444,7 +1444,8 @@ proc default_gdb_spawn { } {
perror "Spawning $GDB failed."
return 1
}
- set gdb_spawn_id -1
+
+ set gdb_spawn_id $res
return 0
}
@@ -1516,6 +1517,24 @@ proc default_gdb_start { } {
return 0
}
+# Utility procedure to give user control of the gdb prompt in a script. It is
+# meant to be used for debugging test cases, and should not be left in the
+# test cases code.
+
+proc gdb_interact { } {
+ global gdb_spawn_id
+ set spawn_id $gdb_spawn_id
+
+ send_user "+------------------------------------------+\n"
+ send_user "| Script interrupted, you can now interact |\n"
+ send_user "| with by gdb. Type >>> to continue. |\n"
+ send_user "+------------------------------------------+\n"
+
+ interact {
+ ">>>" return
+ }
+}
+
# Examine the output of compilation to determine whether compilation
# failed or not. If it failed determine whether it is due to missing
# compiler or due to compiler error. Report pass, fail or unsupported
@@ -191,7 +191,7 @@ proc default_mi_gdb_start { args } {
return -1
}
}
- set gdb_spawn_id -1
+ set gdb_spawn_id $res
# FIXME: mi output does not go through pagers, so these can be removed.
# force the height to "unlimited", so no pagers get used
@@ -78,7 +78,7 @@ proc default_prompt_gdb_start { } {
return -1
}
}
- set gdb_spawn_id -1
+ set gdb_spawn_id $res
return 0
}