Re: [patchv2] Write bpt at the ON_STACK bpt address

["Maciej W. Rozycki" <macro@codesourcery.com>]

On Fri, 27 Jul 2012, Jan Kratochvil wrote:

> >  Does it need native testing or is remote testing enough to cover it?
> 
> I do not think it matters, infcalls work the same for both.

 Breakpoints may be inserted differently on some remote targets, but 
that's more a matter of Linux vs bare-iron targets.  Anyway, thanks for 
confirming that no native testing is required, this is always problematic.

> As Philippe has already tested mips compatibility with valgrind only GDB
> testsuite in some of the appropriate MIPS ISAs would be nice before I check it
> in also for 7.5.

 I have tested your change now, applied on top of current trunk and that 
caused no regressions throughout all the configurations involved, so it 
looks good to go in as far as I'm concerned.

 Sadly there are some regressions in the baseline I used, compared to the 
last previous test results I obtained a couple weeks ago.  Specifically 
these:

FAIL: gdb.base/dprintf.exp: 1st dprintf, gdb
FAIL: gdb.base/dprintf.exp: 2nd dprintf, gdb

FAIL: gdb.base/list.exp: list range; filename:line1,filename:line2
FAIL: gdb.base/list.exp: list range; line1,line2
FAIL: gdb.base/list.exp: list range; upper bound past EOF
FAIL: gdb.base/list.exp: list range; both bounds past EOF
FAIL: gdb.base/list.exp: list range, must be same files

FAIL: gdb.linespec/ls-errs.exp: break 3:
FAIL: gdb.linespec/ls-errs.exp: break +10:
FAIL: gdb.linespec/ls-errs.exp: break -10:
FAIL: gdb.linespec/ls-errs.exp: break 3:
FAIL: gdb.linespec/ls-errs.exp: break +10:
FAIL: gdb.linespec/ls-errs.exp: break -10:
FAIL: gdb.linespec/ls-errs.exp: break 3	:
FAIL: gdb.linespec/ls-errs.exp: break +10	:
FAIL: gdb.linespec/ls-errs.exp: break -10	:
FAIL: gdb.linespec/ls-errs.exp: break 3	:
FAIL: gdb.linespec/ls-errs.exp: break +10	:
FAIL: gdb.linespec/ls-errs.exp: break -10	:

(notice the test message duplication in the last series -- that's a bug by 
itself).

 Do any of these ring anyone's bell?  They appear across both Linux and 
bare-iron configurations and all multilibs so must be pretty generic and 
from the log files they look genuine.  Regrettably I haven't yet grown 
myself a regular overnight testing facility so that I could catch such 
issues early.

  Maciej