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

[Yao Qi]

On 06/09/2011 09:09 PM, Yao Qi wrote:
> On 06/09/2011 07:17 PM, Mark Kettenis wrote:
>>> Date: Thu, 09 Jun 2011 17:28:09 +0800
>>> From: Yao Qi <yao@codesourcery.com>
>>>
>>> In current gdb.base/savedregs.exp, signal handler is installed for
>>> signal SIGSEGV, and SIGSEGV is trigger by `*(char *)0 = 0;'.  However,
>>> on non-mmu uclinux system, writing to an address 0x0 doesn't trigger
>>> SIGSEGV.
>>>
>>> In my patch, SIGILL is chosen to replace SIGSEGV.  One assumption here
>>> is that 0xffff is an invalid instruction on all ports.
>>
>> Please don't do this.  You're changing the test significantly.  And
> 
> I don't think the test is changed *significantly*.  The purpose of
> writing to zero, at least in this case, is to trigger a signal, and
> check the register in signal trampoline frame.  Either SIGSEGV or SIGILL
> meets this need.
> 

Mark,
I still believe my explanation above is correct.  The original patch's
explanation is
<http://sourceware.org/ml/gdb-patches/2004-10/msg00475.html> and "The
attached checks that "info frame" doesn't change as the stack evolves."
shows that SIGSEGV is used here to trigger calling to signal handler.

Please let me know if you still believe that replacing SIGSEGV by other
signals change the test significantly.

>> there is no guarantee that 0xffff is an invalid instruction.  Heck
>> most platforms don't even have 16-bit instructions.
> 
> It is possible to find a `common' invalid instruction over all ports,
> even 0xffff may not be.
> 

This part is weak, I think.  In my second version of this patch, I am
using SIGALRM to replace SIGSEGV.

Tested this new patch on
i686-pc-linux-gnu/x86_64-unknown-linux-gnu/armv7l-unknown-linux-gnu-eabi/my-uclinux-new-port/.
 No new fails.

OK for mainline?

-- 
Yao (齐尧)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: savedregs_sigsegv_to_sigalrm.patch
Type: text/x-patch
Size: 1180 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20110620/5adfef38/attachment.bin>