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

[Andrew Cagney]

> 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?

s/we/the kernel/

The kernel executed both the system call and the breakpoint instruction 
before returning control to GDB.  This is a true loose loose situtation:
- GDB thinks its single stepping
- and that there's no bp at $pc
- and hence that after the single step there won't be a reason for decr 
PC after break
outch!

Another pattern wouldn't hurt.