This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]