[Bug testsuite/34471] New: [gdb/testsuite] expect lookahead matching problem on ppc64-linux

https://sourceware.org/bugzilla/show_bug.cgi?id=3D34471

            Bug ID: 34471
           Summary: [gdb/testsuite] expect lookahead matching problem on
                    ppc64-linux
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: testsuite
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

On ppc64-linux, with test-case gdb.python/py-selected-context.exp I run int=
o:
...
(gdb) info inferiors^M
  Num  Description       Connection           Executable        ^M
  1    <null>                                                   ^M
* 2    <null>                                                   ^M
(gdb) FAIL: $exp: check inferior 2 was selected
...

In contrast, on x86_64-linux, I get:
...
(gdb) info inferiors^M
  Num  Description       Connection           Executable        ^M
  1    <null>                                                   ^M
* 2    <null>                                                   ^M
(gdb) PASS: $exp: check inferior 2 was selected
...

The output is identical, so it's surprising that there's a different
outcome.

The proc doing the check is:
...
proc check_inferior { inf testname } {
    gdb_test "info inferiors" \
        "\r\n\\*\\s+[string_to_regexp $inf]\\s+\[^\r\n\]*(?=3D\r\n)" \
        $testname
}
...

The problem seems to be triggered by the lookahead part '(?=3D\r\n)': remov=
ing
it makes the test pass.

By switching on some debugging in gdb_test_multiple, we get this info:
...
Looking to match ""(?:\r\n\*\s+2\s+[^\r\n]*(?=3D\r\n))\r\n\(gdb\) $""
...
which shows that the lookahead '(?=3D\r\n)' is immediately followed by a '\=
r\n',
making the lookahead superfluous.

I managed to reduce the proc to this:
...
    send_gdb "info inferiors\n"
    expect {
        -i "$::gdb_spawn_id" -re {(?=3D\r\n)\r\n\(gdb\) $} {
            pass $testname
        }
        timeout {
            fail "$testname (timeout)"
        }
    }
...

The failure still reproduces, and removing the lookahead part in the regexp
still makes the test pass.

As a next step, I wrote a standalone expect reproducer:
...
$ cat test.exp
#!/usr/bin/expect

set str "all"

set re {(?=3Da)all}

# Matches here:
puts [regexp $re $str]

spawn sh -c "cat <<'EOF'
$str
EOF"

# But not here:
expect {
    -re $re {
        puts "PASS"
    }
}
...

Using "exp_internal 1" we get some debug info.

On ppc64-linux we have:
...
Gate keeper glob pattern for '(?=3Da)all' is 'aall'. Activating booster.
...

And on x86_64-linux we have:
...
Gate keeper glob pattern for '(?=3Da)all' is 'all'. Activating booster.
...

Note 'aall' vs 'all'.

This is with expect 5.45.4.

This could be an expect bug.

It also could be a miscompilation.  The ppc64-linux distro is Debian GNU/Li=
nux
forky/sid with system gcc "15.3.0 (Debian 15.3.0-2)". FWIW, cfarm121.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=