Re: [rfa] New test sigbpt.{c,exp}

[Daniel Jacobowitz <drow at false dot org>]

On Tue, Jul 06, 2004 at 11:10:07AM -0400, Andrew Cagney wrote:
> >mec> Can you make more of the test names more unique?
> >ac> Oops, I thought I'd covered that.  Try the attached.
> >
> >It works for me.
> >All the test names are unique except for "rerun to main".
> >Stil the same four FAILs but that's okay because they really are FAILs.
> >
> >I approve this patch.
> >
> >ac> Are there [get_kernel_info] and [get_software_singlestep] testsuite 
> >calls?
> >
> >I don't know of any.
> >
> >I'm a bit leery of "get_kernel_info", because we should be testing
> >for features rather than version numbers (the whole autoconf philosophy).
> >Although get_compiler_info has worked reasonably well for the job
> >that it does.
> >
> >I'm more inclined to dump a bunch of KFAIL's into the gdb_test_multiple
> >arms for the bad results, along with comments about which kernel versions
> >have been observed to have which behavior.  Then in 3-5 years it's not
> >hard to sort out the obsolete crap.
> >
> >If KFAIL's are too hard then just the comments for starters.
> 
> I both kfailed and and commented, committing the attached.

I get:
KFAIL: gdb.base/sigbpt.exp: stepi out of handler; stepi (executed fault insn) (PRMS: gdb/1702)
KFAIL: gdb.base/sigbpt.exp: stepi out of handler; stepi bp before segv (executed fault insn) (PRMS: gdb/1702)
FAIL: gdb.base/sigbpt.exp: stepi out of handler; stepi bp at segv
FAIL: gdb.base/sigbpt.exp: stepi out of handler; stepi bp before and at segv

0x080483f2 in bowler () at /opt/src/gdb/src/gdb/testsuite/gdb.base/sigbpt.c:38
38        return *(char *) (v1 + v2 + v3);
1: x/i $pc  0x80483f2 <bowler+25>:      mov    $0x55c35d00,%esi
(gdb) FAIL: gdb.base/sigbpt.exp: stepi out of handler; stepi bp at segv

That's not the instruction that should be there; there's a multi-byte
instruction at <bowler+24>.  My suspicion is that we single-stepped
with breakpoints inserted and no trap was triggered for the breakpint
at 0x80483f2 for whatever kernel reason.  Make sense?  If so, shall I
try to find a way to kfail this?


-- 
Daniel Jacobowitz