Re: [RFA] Re: x86 linux GDB and SIGALRM

[Andrew Cagney <ac131313 at cygnus dot com>]

Mark Kettenis wrote:
> 
>    Date: Tue, 02 May 2000 10:48:57 +1000
>    From: Andrew Cagney <ac131313@cygnus.com>
> 
>    I think your analysis of the history is correct.  I'd just like to
>    (infrun.c is the most frail code of code in GDB) see a testsuite
>    addition (is there one already?) and a yay from someone with threads on
>    a non-linux target.  I just have a feeling that creating a test case
>    isn't easy :-( Hmm, does steping through a SIGBUS trigger the behavour?
> 
> I'll test it on Solaris 2.6.  I already promised Stan a testcase.
> Would you prefer a SIGBUS/SIGSEGV testcase, or rather a SIGALRM
> testcase?  I actually think the SIGALRM one is easier, but of course
> there are targets without SIGALRM.  Do you know any targets that do
> #define SIGALRM, but don't actually support it?

Yes, many :-(

Regardless, I would suggest setting a test up for a UNIX environment and
then someone (me?) will have to figure out how to have it work in a
non-unix embedded environment.

>    Actually, lets see:
> 
>    With out the patch:
> 
>            (gdb) handle SIGBUS pass print nostop
>            (gdb) b *0x1014064
>            (gdb) run
>            Breakpoint 3, 0x1014064 in test_ld ()
>            (gdb) stepi
>            Program received signal SIGBUS, Bus error.
>            0x1014064 in test_ld ()
> 
> That's what would be expected for
> 
>            (gdb) handle SIGBUS pass print stop
> 
> isn't it?

Hmm, yes.  Making it wrong for ``nostop'' which I specifed.

>    with the patch:
> 
>            (gdb) handle SIGBUS pass print nostop
>            (gdb) break *0x1014064
>            Breakpoint 1 at 0x1014064
>            (gdb) run
>            Breakpoint 1, 0x1014064 in test_ld ()
>            (gdb) stepi
> 
>            Program received signal SIGBUS, Bus error.
>            0x103ff10 in ?? ()
>            (gdb)
> 
>    is that the intended behavour?  I should note that this is a simulator
>    target which can single step through exceptions.  Normal targets most
>    likely just continue until the exception returns?
> 
> I'm not sure exactly what you mean by single stepping through
> exceptions.  But I assume 0x103ff10 is the first (or perhaps second)
> instruction of the exception handler for SIGBUS?

0x103ff10 is the first instruction of the hardware exception handler. 
It is like single stepping a system call instruction and finding
yourself inside of the kernel.

Anyway, this makes the modified behavour reasonable in a simulated
environment.

Definitly ok with me,

	Andrew