Strange behavior of sigstep-threads.exp?

[Andreas Arnez <arnez@linux.vnet.ibm.com>]

On x86-64 with upstream GDB, I'm observing what I consider strange
behavior of the sigstep-threads.exp test case.

Here's an excerpt from the log file:

  32        var++;                /* step-1 */
  (gdb) disable $step1
  (gdb) step

  Program received signal SIGUSR1, User defined signal 1.

  Program received signal SIGUSR1, User defined signal 1.

  Program received signal SIGUSR1, User defined signal 1.

  Program received signal SIGUSR1, User defined signal 1.
  33        tgkill (getpid (), gettid (), SIGUSR1);       /* step-2 */

It seems that running from step-1 to step-2 produced four SIGUSR1.  And
in total ca. 3 times as many signals are encountered than we pass
tgkill()'s:

  $ grep tgkill gdb.log | wc
      100    1000    5900
  $ grep 'Program received signal SIGUSR1' gdb.log | wc
      310    2480   17670

From the code I wouldn't expect that.  Is this a known bug or expected
behavior?  Note that the test case doesn't fail, since it doesn't care
about the number of incoming signals.

On s390x the test case actually fails sometimes.  In those cases, when
stepping from step-1 to step-2, a ton of SIGUSR1 are indicated, and then
the inferior seems to stop at the closing brace of the handler()
function instead of the tgkill().