Re: Remaining 7.5 regressions (Re: [ARM, commit, RFA 7.5] Fix HW breakpoints on unaligned addresses)

["Ulrich Weigand" <uweigand@de.ibm.com>]

Sergio Durigan Junior wrote:
> On Wednesday, August 01 2012, Ulrich Weigand wrote:
> > In addition to the failures fixed by the above patches, I'm still seeing:
> >
> > - Failures in gdb.base/pc-fp.exp on various platforms, as described here:
> >   http://sourceware.org/ml/gdb-patches/2012-07/msg00823.html
> >   (just an output formatting issue)
> 
> This patch will probably go in tomorrow when I wake up, if Pedro
> approves it.  It is also simple enough to be committed to 7.5.

OK, thanks!
 
> > - Failures in gdb.mi/mi-var-rtti.exp on various platforms, see:
> >   http://sourceware.org/ml/gdb-patches/2012-07/msg00458.html
> >   (seems to be a bug in the test case)
> 
> I see them also on s390x as you pointed out, but not on ppc64.

Well, the test case reads uninitialized stack contents, so the
particulars of the effect can well depend on the platform ...

> > - Failures in gdb.threads/watchpoint-fork.exp on ARM and PowerPC.
> >   This looks like a pre-existing bug that hardware watchpoints are not
> >   handled correctly across forks, which is now exposed since a test
> >   case for this scenario was added.
> 
> I seem some failures on s390x as well:
> 
>     +FAIL: gdb.threads/watchpoint-fork.exp: child: singlethreaded: breakpoint after the second fork (timeout)
>     +FAIL: gdb.threads/watchpoint-fork.exp: child: singlethreaded: watchpoint after the second fork
>     +FAIL: gdb.threads/watchpoint-fork.exp: child: singlethreaded: finish

Yes, it's the same issue.

> > - Some new C++ regressions on ARM / s390x (could be compiler issues?)
> 
> Could you tell which C++ regressions are those?  I see this on
> PPC64/s390x:
> 
> -PASS: gdb.cp/inherit.exp: print g_vB (FIXME v3 vtbl ptr)
> -PASS: gdb.cp/inherit.exp: print g_vC (FIXME v3 vtbl ptr)
> +FAIL: gdb.cp/inherit.exp: print g_vB
> +FAIL: gdb.cp/inherit.exp: print g_vC
> ...
> -PASS: gdb.cp/inherit.exp: print g_vE (FIXME v3 vtbl ptr)
> +FAIL: gdb.cp/inherit.exp: print g_vE
> 
> -PASS: gdb.cp/virtbase.exp: print *this
> +FAIL: gdb.cp/virtbase.exp: print *this
> ...
> -PASS: gdb.cp/virtbase.exp: print *(D *) e
> +FAIL: gdb.cp/virtbase.exp: print *(D *) e

Exactly, those are the ones.  I haven't looked further ...

> > - Failures in various core file tests on PowerPC (needs investigation)
> 
> I am not seeing this on ppc64 RHEL 6.3.

This is actually not a PowerPC but a general problem; in fact it is a problem
with older kernels (I happen to run my PowerPC tests on RHEL 5 since RHEL 6
no longer supports Cell).  My patch series to make "info proc" work remotely
caused GDB to use "pread" instead of "read" to access /proc/.../maps -- and
on older kernels this just errors out with -ESPIPE.

I'm testing a patch to fall back to lseek/read if that happens.

> > - Failures in gdb.threads/siginfo-threads.exp on s390 (needs investigation)
> 
> Fully passing for me on s390x RHEL 6.3.

The failure happens only when testing with -m31; apparently the signal info
struct isn't properly converted between 31-bit and 64-bit format.

B.t.w. I'm now seeing the same issue on PowerPC with -m32 on a 64-bit
kernel ...

> > - Failures in gdb.dwarf2/dw2-icc-opaque.exp on SPU and s390 (likewise)
> 
> I can confirm on s390x, and I am also seeing on ppc64.

It's a test case bug; I'll commit a patch shortly.

In addition, I also have patches for these issues (likewise testsuite):

> - Failures in watchpoint.exp on SPU (needs investigation)
> 
> - Failures in gdb.dwarf2/dw2-icc-opaque.exp on SPU and s390 (likewise)
> 
> - Testcase harness failures when running a multi-lib configuration:
>    ERROR: tcl error sourcing ../../../gdb-7_5/gdb/testsuite/gdb.base/inferior-died.exp.
>    ERROR: can't set "seen": variable is array
>    ERROR: tcl error sourcing /home/uweigand/fsf/gdb-head/gdb/testsuite/gdb.threads/linux-dp.exp.
>    ERROR: can't array set "seen": variable isn't array
>   (Invalid re-use of a variable name?)

and I understood the reason for this issue:

> - Failures in gdb.server tests on SPU (needs investigation)

which is that the SPU gdbserver does not support multi-process mode.


Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com