[Bug gdb/19675] GDB doesn't set PC correctly with displaced stepping over clone syscall

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=99ba4b64d3636533f3659a9c7d3e8504ca93c770

commit 99ba4b64d3636533f3659a9c7d3e8504ca93c770
Author: Andrew Burgess <andrew.burgess@embecosm.com>
Date:   Tue Jun 8 12:49:04 2021 +0100

    gdb/testsuite: update test gdb.base/step-over-syscall.exp

    I was looking at PR gdb/19675 and the related test
    gdb.base/step-over-syscall.exp.  This test includes a call to kfail
    when we are testing a displaced step over a clone syscall.

    While looking at the test I removed the call to kfail and ran the
    test, and was surprised that the test passed.

    I ran the test a few times and it does sometimes fail, but mostly it
    passed fine.

    PR gdb/19675 describes how, when we displaced step over a clone, the
    new thread is created with a $pc in the displaced step buffer.  GDB
    then fails to "fix" this $pc (for the new thread), and the thread will
    be set running with its current $pc value.  This means that the new
    thread will just start executing from whatever happens to be after the
    displaced stepping buffer.

    In the original PR gdb/19675 bug report Yao Qi was seeing the new
    thread cause a segfault, the problem is, what actually happens is
    totally undefined.

    On my machine, I'm seeing the new thread reenter main, it then starts
    trying to run the test again (in the new thread).  This just happens
    to be safe enough (in this simple test) that most of the time the
    inferior doesn't crash.

    In this commit I try to make the test slightly more likely to fail by
    doing a couple of things.

    First, I added a static variable to main, this is set true when the
    first thread enters main, if a second thread ever enters main then I
    force an abort.

    Second, when the test is finishing I want to ensure that the new
    threads have had a chance to do "something bad" if they are going to.
    So I added a global counter, as each thread starts successfully it
    decrements the counter.  The main thread does not proceed to the final
    marker function (where GDB has placed a breakpoint) until all threads
    have started successfully.  This means that if the newly created
    thread doesn't successfully enter clone_fn then the counter will never
    reach zero and the test will timeout.

    With these two changes my hope is that the test should fail more
    reliably, and so, I have also changed the test to call setup_kfail
    before the specific steps that we expect to misbehave instead of just
    calling kfail and skipping parts of the test completely.  The benefit
    of this is that if/when we fix GDB this test will start to KPASS and
    we'll know to update this test to remove the setup_kfail call.

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