This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patchv2] Write bpt at the ON_STACK bpt address
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