Re: [PATCH v3 0/4] gdb: add gdb_attach to fix failed testcases

[Pedro Alves <pedro@palves.net>]

On 2022-03-18 01:53, Tiezhu Yang wrote:
> 
> 
> On 03/18/2022 12:55 AM, Pedro Alves wrote:
>> On 2022-03-17 14:00, Tiezhu Yang wrote:
>>> Hi Simon and Pedro,
>>>
>>> Thank you very much for your suggestions.
>>> Please review this v3 patchset.
>>> Any comments will be much appreciated.
>>
>> Thanks for doing this.
>>
>> Are these really the only .exp files that need to use gdb_attach?  Or is it just
>> that you're tackling this incrementally?
>>
> 
> At least for now, attach-pie-noexec.exp and jit-elf.exp need to use
> gdb_attach to fix the failed testcases, if we find the other .exp
> files also have similar issues in the future, I will tackling them
> incrementally.

On a first approximation, I'd think most of the tests that use can_spawn_for_attach
would need to be adjusted.

 gdb.threads/detach-step-over.exp:51:if {![can_spawn_for_attach]} {
 gdb.threads/attach-many-short-lived-threads.exp:52:if {![can_spawn_for_attach]} {
 gdb.threads/clone-attach-detach.exp:26:if {![can_spawn_for_attach]} {
 gdb.threads/attach-non-stop.exp:22:if {![can_spawn_for_attach]} {
 gdb.base/attach.exp:16:if {![can_spawn_for_attach]} {
 gdb.base/kill-detach-inferiors-cmd.exp:21:if ![can_spawn_for_attach] {
 gdb.base/watchpoint-hw-attach.exp:23:if {![can_spawn_for_attach]} {
 gdb.base/solib-overlap.exp:34:if {![can_spawn_for_attach]} {
 gdb.base/random-signal.exp:70:    if {[can_spawn_for_attach]} {
 gdb.base/jit-elf.exp:151:if {[can_spawn_for_attach]} {
 gdb.base/interrupt-daemon-attach.exp:27:if { ![can_spawn_for_attach] } {
 gdb.base/attach-non-pgrp-leader.exp:21:if {![can_spawn_for_attach]} {
 gdb.base/attach-pie-noexec.exp:16:if {![can_spawn_for_attach]} {
 gdb.base/corefile.exp:290:    if [can_spawn_for_attach] {
 gdb.base/run-attach-while-running.exp:38:    if { ${run-or-attach} == "attach" && ![can_spawn_for_attach] } {
 gdb.base/quit-live.exp:168:    if {$appear_how != "run" && ![can_spawn_for_attach]} {
 gdb.base/attach-twice.exp:16:if {![can_spawn_for_attach]} {
 gdb.base/bp-cmds-continue-ctrl-c.exp:137:    if {[can_spawn_for_attach]} {
 gdb.base/run-after-attach.exp:19:if ![can_spawn_for_attach] {
 gdb.base/jit-attach-pie.exp:16:if {![can_spawn_for_attach]} {
 gdb.python/py-sync-interp.exp:23:if {![can_spawn_for_attach]} {
 gdb.python/py-prompt.exp:81:if {![can_spawn_for_attach]} {
 gdb.server/attach-flag.exp:28:if {![can_spawn_for_attach]} {
 gdb.server/ext-attach.exp:29:if {![can_spawn_for_attach]} {
 gdb.multi/multi-attach.exp:22:if {![can_spawn_for_attach]} {
 gdb.multi/multi-term-settings.exp:28:if ![can_spawn_for_attach] {
 gdb.mi/list-thread-groups-available.exp:38:if ![can_spawn_for_attach] {

My main "worry" (not very serious), is that we discover that some test
is currently using gdb_test_multiple to expect more than one potential
output after "attach ...", which can't be mapped to gdb_attach as is.  That
would suggest that gdb_attach would be better redesigned as a wrapper around
gdb_test_multiple with some internal matches, rather than passing down
the expected pattern with "-pattern".

if ![!gdb_test_attach_multiple "attach 123" "testname" {
   -re -wrap "foo bar output 1" {
       pass "$gdb_test_name (v1)"
    }
   -re -wrap "foo bar output 2" {
       pass "$gdb_test_name (v2)"
    }
}] {
  return
}

Maybe we'd call it gdb_test_attach_multiple, and then add a gdb_test_attach
wrapper around it that would be just like gdb_test vs gdb_test_multiple.  That
would suggest that gdb_test_attach wouldn't be using options like "-pattern"
at all.