x86 linux GDB and SIGALRM

x86 linux GDB and SIGALRM

[Jonathan Larmour]

I have an x86 Linux program here that uses SIGALRM for regular periodic
"interrupts". SIGVTALRM isn't really precise enough for it's needs.

However I noticed that "si" doesn't work - it interferes with the ptrace/GDB
interface. It seems that when ptrace(PTRACE_SINGLESTEP,...) returns, a
SIGALRM is pending, and the single step gets lost.

Now this works in GDB 4.18 so this is a regression. But does anyone have any
clues as to what's *meant* to be going on here, and how I fix GDB?

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: x86 linux GDB and SIGALRM

[Andrew Cagney]

Jonathan Larmour wrote:
> 
> I have an x86 Linux program here that uses SIGALRM for regular periodic
> "interrupts". SIGVTALRM isn't really precise enough for it's needs.
> 
> However I noticed that "si" doesn't work - it interferes with the ptrace/GDB
> interface. It seems that when ptrace(PTRACE_SINGLESTEP,...) returns, a
> SIGALRM is pending, and the single step gets lost.
> 
> Now this works in GDB 4.18 so this is a regression. But does anyone have any
> clues as to what's *meant* to be going on here, and how I fix GDB?

Can anyone independantly confirm/deny this?

	Andrew

Re: x86 linux GDB and SIGALRM

[Mark Kettenis]

   Date: Mon, 27 Mar 2000 20:00:57 +1000
   From: Andrew Cagney <ac131313@cygnus.com>

   Jonathan Larmour wrote:
   > 
   > I have an x86 Linux program here that uses SIGALRM for regular
   > periodic "interrupts". SIGVTALRM isn't really precise enough for
   > it's needs.
   > 
   > However I noticed that "si" doesn't work - it interferes with the
   > ptrace/GDB interface. It seems that when
   > ptrace(PTRACE_SINGLESTEP,...) returns, a SIGALRM is pending, and
   > the single step gets lost.
   > 
   > Now this works in GDB 4.18 so this is a regression. But does
   > anyone have any clues as to what's *meant* to be going on here,
   > and how I fix GDB?

   Can anyone independantly confirm/deny this?

No, but I'd like to see if I can reproduce the problem.  Jonathan, can
you provide a small test program and detailed instructions (typescript
of a GDB session) on how to do that?

I know there are problems with single stepping through signal
handlers.  These problems were present in 4.18.  They were just masked
because 4.18 failed to recognize signal handlers.  Fixing it is not
easy, and will require changes to handle_inferior_event(), that I
prefer not to make before the 5.0 release.

Mark

Re: x86 linux GDB and SIGALRM

[Mark Kettenis]

   Date: Mon, 27 Mar 2000 20:00:57 +1000
   From: Andrew Cagney <ac131313@cygnus.com>

   Jonathan Larmour wrote:
   > 
   > I have an x86 Linux program here that uses SIGALRM for regular
   > periodic "interrupts". SIGVTALRM isn't really precise enough for
   > it's needs.
   > 
   > However I noticed that "si" doesn't work - it interferes with the
   > ptrace/GDB interface. It seems that when
   > ptrace(PTRACE_SINGLESTEP,...) returns, a SIGALRM is pending, and
   > the single step gets lost.
   > 
   > Now this works in GDB 4.18 so this is a regression. But does
   > anyone have any clues as to what's *meant* to be going on here,
   > and how I fix GDB?

   Can anyone independantly confirm/deny this?

No, but I'd like to see if I can reproduce the problem.  Jonathan, can
you provide a small test program and detailed instructions (typescript
of a GDB session) on how to do that?

I know there are problems with single stepping through signal
handlers.  These problems were present in 4.18.  They were just masked
because 4.18 failed to recognize signal handlers.  Fixing it is not
easy, and will require changes to handle_inferior_event(), that I
prefer not to make before the 5.0 release.

Mark

x86 linux GDB and SIGALRM

[Jonathan Larmour]

I have an x86 Linux program here that uses SIGALRM for regular periodic
"interrupts". SIGVTALRM isn't really precise enough for it's needs.

However I noticed that "si" doesn't work - it interferes with the ptrace/GDB
interface. It seems that when ptrace(PTRACE_SINGLESTEP,...) returns, a
SIGALRM is pending, and the single step gets lost.

Now this works in GDB 4.18 so this is a regression. But does anyone have any
clues as to what's *meant* to be going on here, and how I fix GDB?

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

Re: x86 linux GDB and SIGALRM

[Andrew Cagney]

Jonathan Larmour wrote:
> 
> I have an x86 Linux program here that uses SIGALRM for regular periodic
> "interrupts". SIGVTALRM isn't really precise enough for it's needs.
> 
> However I noticed that "si" doesn't work - it interferes with the ptrace/GDB
> interface. It seems that when ptrace(PTRACE_SINGLESTEP,...) returns, a
> SIGALRM is pending, and the single step gets lost.
> 
> Now this works in GDB 4.18 so this is a regression. But does anyone have any
> clues as to what's *meant* to be going on here, and how I fix GDB?

Can anyone independantly confirm/deny this?

	Andrew

Re: x86 linux GDB and SIGALRM

[Jonathan Larmour]

Mark Kettenis wrote:
> 
>    Date: Mon, 27 Mar 2000 20:00:57 +1000
>    From: Andrew Cagney <ac131313@cygnus.com>
> 
>    Jonathan Larmour wrote:
>    >
>    > I have an x86 Linux program here that uses SIGALRM for regular
>    > periodic "interrupts". SIGVTALRM isn't really precise enough for
>    > it's needs.
>    >
>    > However I noticed that "si" doesn't work - it interferes with the
>    > ptrace/GDB interface. It seems that when
>    > ptrace(PTRACE_SINGLESTEP,...) returns, a SIGALRM is pending, and
>    > the single step gets lost.
>    >
>    > Now this works in GDB 4.18 so this is a regression. But does
>    > anyone have any clues as to what's *meant* to be going on here,
>    > and how I fix GDB?
> 
>    Can anyone independantly confirm/deny this?
> 
> No, but I'd like to see if I can reproduce the problem.  Jonathan, can
> you provide a small test program and detailed instructions (typescript
> of a GDB session) on how to do that?
> 
> I know there are problems with single stepping through signal
> handlers.  These problems were present in 4.18.  They were just masked
> because 4.18 failed to recognize signal handlers.  Fixing it is not
> easy, and will require changes to handle_inferior_event(), that I
> prefer not to make before the 5.0 release.

Sorry for the delay in getting back to you on this. I've attached a test
case for you. Virtual timers are no problem, it's only real-time timers
that cause the problem.

Here's a GDB session. As you can see "stepi"s don't work, but "step"s and
"next"s do.

(gdb) b breakme
Breakpoint 1 at 0x80484ee: file sigalrm.c, line 19.
(gdb) run
Starting program: /n/tikka/home/jlarmour/c/sigalrm

Breakpoint 1, breakme () at sigalrm.c:19
19          struct timeval tv = { 0, 0 };
(gdb) disp/i $pc
1: x/i $eip  0x80484ee <breakme+6>:     movl   $0x0,0xfffffff8(%ebp)
(gdb) si
19          struct timeval tv = { 0, 0 };
1: x/i $eip  0x80484ee <breakme+6>:     movl   $0x0,0xfffffff8(%ebp)
(gdb)
19          struct timeval tv = { 0, 0 };
1: x/i $eip  0x80484ee <breakme+6>:     movl   $0x0,0xfffffff8(%ebp)
(gdb)
19          struct timeval tv = { 0, 0 };
1: x/i $eip  0x80484ee <breakme+6>:     movl   $0x0,0xfffffff8(%ebp)
(gdb) step
21          printf("Got %d alarms\n", alarms);
1: x/i $eip  0x80484fc <breakme+20>:    add    $0xfffffff8,%esp
(gdb) next
Got 8 alarms
22          select(0, NULL, NULL, NULL, &tv);
1: x/i $eip  0x8048512 <breakme+42>:    add    $0xfffffff4,%esp
(gdb) si
22          select(0, NULL, NULL, NULL, &tv);
1: x/i $eip  0x8048512 <breakme+42>:    add    $0xfffffff4,%esp
(gdb)
22          select(0, NULL, NULL, NULL, &tv);
1: x/i $eip  0x8048512 <breakme+42>:    add    $0xfffffff4,%esp
(gdb)

When I changed the itimer interval to 50000usecs from 5000usecs, then I got
mixed behaviour with some instructions stepping working, and some not. If
using e.g. 1 second, instruction stepping appears to work. This is
presumably all due to whether a SIGALRM is pending when ptrace returns.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault
#include <signal.h>
#include <stddef.h>
#include <sys/time.h>

#define ALRM

volatile int alarms;

static void 
handler( int signum )
{
    alarms++;
}


static void
breakme(void)
{
    struct timeval tv = { 0, 0 };

    printf("Got %d alarms\n", alarms);
    select(0, NULL, NULL, NULL, &tv); 
}

int main(int argc, char *argv[])
{
    struct sigaction act;
    sigset_t set;
    struct itimerval itv;

    act.sa_handler = &handler;
    sigemptyset(&set);
    act.sa_mask = set;
    act.sa_flags = 0;

    sigaction(SIGALRM, &act, NULL);
    sigaction(SIGVTALRM, &act, NULL);

    itv.it_interval.tv_sec = 0;
    itv.it_interval.tv_usec = 5000;
    itv.it_value.tv_sec = 0;
    itv.it_value.tv_usec = 5000;
#ifdef ALRM
    setitimer(ITIMER_REAL, &itv, NULL);
#else
    setitimer(ITIMER_VIRTUAL, &itv, NULL);
#endif

    for (;;)
        breakme();
    return 0;
}

[RFA] Re: x86 linux GDB and SIGALRM

[Mark Kettenis]

[ There is a comment right before this code by JimB, so maybe you want
  to comment on this Jim. ]

I think I've found the bug that's causing the problem Jonathan was
seeing.  This patch restores the behaviour of GDB 4.18.  GDB 4.18 was
released before handle_inferior_event() was introduced.  At the point
of the check_sigtramp2() call there was a "goto check_sigtramp2".
Since in the old situation after the check_sigtramp2 code the
keep_going label would be reached, I think that the we should call
keep_going() here and return.

If we don't this we'll land in the breakpoint handling code.  The
breakpoint handling code has the side-effect of cancelling any single
stepping and stopping right away.  Now if we single step, but the
OS arranges to actually pass us a pending signal before actually
stepping (which is what happens on Linux/i386), we'll never step and
we see the behaviour that Jonathan observed.

[ Perhaps I should modify the comment a bit, now that the code
  actually does keep_going. ]

Mark


2000-05-01  Mark Kettenis  <kettenis@gnu.org>

	* infrun.c (handle_inferior_event): Add missing call to keep_going
	and missing return when handling an ordinary signal from the
	inferior.


Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.8
diff -u -p -r1.8 infrun.c
--- infrun.c	2000/04/20 11:00:34	1.8
+++ infrun.c	2000/05/01 18:43:13
@@ -2274,6 +2274,8 @@ handle_inferior_event (struct execution_
            the HP-UX maintainer to furnish a fix that doesn't break other
            platforms.  --JimB, 20 May 1999 */
 	check_sigtramp2 (ecs);
+	keep_going (ecs);
+	return;
       }
 
     /* Handle cases caused by hitting a breakpoint.  */

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

[Jim Blandy]

I last changed this code to allow GDB to step over calls to
pthread_create properly.  If you can still do a "next" over a call to
pthread_create after your change, I have no further comments.  The
test gdb.threads/linux-dp.exp ought to run on Linux and verify that
this works.



> [ There is a comment right before this code by JimB, so maybe you want
>   to comment on this Jim. ]
> 
> I think I've found the bug that's causing the problem Jonathan was
> seeing.  This patch restores the behaviour of GDB 4.18.  GDB 4.18 was
> released before handle_inferior_event() was introduced.  At the point
> of the check_sigtramp2() call there was a "goto check_sigtramp2".
> Since in the old situation after the check_sigtramp2 code the
> keep_going label would be reached, I think that the we should call
> keep_going() here and return.
> 
> If we don't this we'll land in the breakpoint handling code.  The
> breakpoint handling code has the side-effect of cancelling any single
> stepping and stopping right away.  Now if we single step, but the
> OS arranges to actually pass us a pending signal before actually
> stepping (which is what happens on Linux/i386), we'll never step and
> we see the behaviour that Jonathan observed.
> 
> [ Perhaps I should modify the comment a bit, now that the code
>   actually does keep_going. ]
> 
> Mark
> 
> 
> 2000-05-01  Mark Kettenis  <kettenis@gnu.org>
> 
> 	* infrun.c (handle_inferior_event): Add missing call to keep_going
> 	and missing return when handling an ordinary signal from the
> 	inferior.
> 
> 
> Index: infrun.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/infrun.c,v
> retrieving revision 1.8
> diff -u -p -r1.8 infrun.c
> --- infrun.c	2000/04/20 11:00:34	1.8
> +++ infrun.c	2000/05/01 18:43:13
> @@ -2274,6 +2274,8 @@ handle_inferior_event (struct execution_
>             the HP-UX maintainer to furnish a fix that doesn't break other
>             platforms.  --JimB, 20 May 1999 */
>  	check_sigtramp2 (ecs);
> +	keep_going (ecs);
> +	return;
>        }
>  
>      /* Handle cases caused by hitting a breakpoint.  */
>