>>                              64-bit            32-bit
>>                          before  after     before  after
>>  expected passes          41792  41802      41687  41541
>>  unexpected failures       2346   2343       2302   2294
>>  unexpected successes         1      1          1      1
>>  expected failures           17     17         15     15
>>  known failures              30     30         30     30
>>  unresolved testcases        30     29         11     86

>I'm a bit concerned about the significant increase of
>unresolved testcases on 32-bit.  This might indicate that
>some of the assumptions about the behavior of ptrace64
>with 32-bit inferiors could be inaccurate.

>Can you look into the root cause of those unresolved cases?

I looked at the 32-bit results from the post-patch run (gdb.base-32.log). The increase in unresolved testcases doesn't look related to ptrace64 or 32-bit inferior handling. 

Of the 86 unresolved testcases, 75 come from a single test file, gdb.base/shell.exp. The other 11 are one each from attach, bp-cmds-continue-ctrl-c, execl-update-breakpoints, gdb-sigterm, interrupt-daemon-attach, jit-bfd-name, jit-elf-fork, jit-elf, longjmp-until-in-main, longjmp and tls-nothreads. 

That is the same count as the baseline run, and the same set that shows up in the 64-bit log, so the whole increase comes from shell.exp. 

The first pipe test in that file, "|p 123| exit 0", failed with:

      ERROR: GDB process no longer exists

      GDB process exited with wait status ... CHILDKILLED SIGPIPE 

      UNRESOLVED: gdb.base/shell.exp: |p 123| exit 0 

Once GDB died, every later test in the file failed with "Couldn't send ... to GDB". That accounts the 75 unresolved results and most of the drop in expected passes. 

The likely cause is in pipe_command in gdb/cli/cli-cmds.c. It uses popen (<args>, "w") and writes the command output to the child. In this test the child command is simply exit 0. If it exits before GDB writes, the write raises SIGPIPE and GDB itself exits. Unlike some other code paths (for example gdb/compile/compile.c), pipe_command doesn't use scoped_ignore_sigpipe. 

Also, shell.exp runs without a program loaded, so it doesn't exercise any code changed by the aix-thread or rs6000-aix-nat patches.

 I was also able to reproduce the race manually by running the equivalent command in a loop, from the gdb build directory: 

      for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20; 

            do 

                  printf 'pipe p 123 | exit 0\nquit\n' | ./gdb -q -nx >/dev/null 2>&1

                  echo "$?”

            done 

One of the 20 runs exited with status 141 (128 + SIGPIPE), and the other 19 exited with 0. 

Here is the output:

0 0 0 0 0 0 0 0 0 0 0 0 141 0 0 0 0 0 0 0

I also re-ran shell.exp alone six times, from gdb/testsuite: 

 gmake check RUNTESTFLAGS="gdb.base/shell.exp"

Results were the same in all six runs: 

 # of expected passes 112 

 # of unexpected failures 4 

There were no unresolved results in any of the six runs. The 4 unexpected failures were the "shell interrupt" and "pipe interrupt" exitcode/exitsignal tests, which use "kill -2 $$". I haven't investigated why they fail on AIX. They are not related to this series. 

Therefore, this appears to be a pre-existing race in pipe_command rather than an effect of this patch series.

Let me know if you need more details.

Thanks and regards,

Aditya.