Re: [patch V2, testsuite] gdb.base/savedregs.exp: SIGSEGV -> SIGALRM

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Mon, 20 Jun 2011 16:26:00 +0800
> From: Yao Qi <yao@codesourcery.com>
> Organization: CodeSourcery
> CC: gdb-patches@sourceware.org
> X-XS4ALL-DNSBL-Checked: mxdrop157.xs4all.nl checked 38.113.113.100 against DNS blacklists
> X-CNFS-Analysis: v=1.1 cv=0zc6fmG9YcuPB4Yp6G+9JUp7sX0X0uIJmZE+jPYAbEE= c=1
> 	sm=0 a=BqqcDBkZDkoA:10 a=JR3SvU1DSgIA:10 a=zbTXIsBlecMA:10
> 	a=BLceEmwcHowA:10 a=IkcTkHD0fZMA:10 a=gA6+7WRReeCfZX6hXOPmZA==:17
> 	a=WZgqnTsFiMBE2RNew4wA:9 a=MWeep4gfJk6IGiYzYrIA:7 a=QEXdDO2ut3YA:10
> 	a=gA6+7WRReeCfZX6hXOPmZA==:117
> X-Virus-Scanned: by XS4ALL Virus Scanner
> X-XS4ALL-Spam-Score: -0.0 () SPF_PASS
> X-XS4ALL-Spam: NO
> Envelope-To: mark.kettenis@xs4all.nl
> 
> On 06/20/2011 03:01 PM, Mark Kettenis wrote:
> > That's an even bigger change.  And I don't think that SIGALRM is even
> > guaranteed to happen before the program terminates.  And if there
> > MMU-less systems that effectively don't support SIGSEGV, there
> > certainly are timer-less systems that don't support SIGALRM.
> > 
> 
> What system doesn't support SIGALRM?  I noticed that SIGALRM is widely
> used in gdb testsuite, so I assume that it is safer to use SIGALRM than
> SIGILL here.
> 
> > Really, just skip this test on MMU-less systems.  If you're worried
> > about test coverage on your MMU-less ARM systems, add an additional
> > test in gdb.arch/ that uses an undefined instruction to generate
> > SIGILL.
> 
> I am afraid it is not a good idea.  There are many MMU-less processor,
> and shall we duplicate this test case all over under gdb.arch/ for each
> MMU-less processor?
> 
> As I pointed out before, this test case has nothing to do with the
> difference of MMU system and MMU-less system.  Originally, SIGSEGV was
> used here to trigger an invocation to signal handler.  The key point of
> this case is "to trigger an invocation to a handler, and check the frame
> in signal handler", so handler of what signal doesn't matter here.
> Then, we should choose a signal which exists on all systems that gdb
> supports.  Firstly, SIGSEGV is chosen, but it doesn't work on MMU-less
> system, then SIGILL and SIGALRM is proposed in my two patches
> respectively, which you don't like.

The fundamental problem with SIGALRM is that it is non-deterministic.
The point where the progrem gets interrupted by the signal can be
different for each run of the test.  That point determines which
unwinder gets used, which may affect the test result.  Using SIGALRM
really is a bad idea for this test.  It might be a bad idea for those
other tests as well.

My concern with using SIGILL (apart from generating an instruction
that forces SIGALL on all architectures we support) is that you're
going to end up testing a different unwinder as well.  Typically in
the SIGSEGV case you'll end up at the faulting instruction, which is
defenitely in the function body, where we should be using the DWARF
CFI unwinder.  But for SIGILL you could end up at the instruction
after the trapping instruction, which is likely to be in the function
epilogue which may be handled by an epilogue unwinder.

> Maybe, another option is to define invalid instruction for each targets
> in test case.

Perhaps a reasonable compromise is to do something like:

static void
thrower (void)
{
  *(char *)0 = 0;
#ifdef __arm__
  asm(".word 0xffff");
#endif
}

and then handle both SIGSEGV and SIGILL.