* x86 linux GDB and SIGALRM @ 2000-03-24 15:04 Jonathan Larmour 2000-03-27 2:03 ` Andrew Cagney 2000-04-01 0:00 ` Jonathan Larmour 0 siblings, 2 replies; 9+ messages in thread From: Jonathan Larmour @ 2000-03-24 15:04 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: x86 linux GDB and SIGALRM 2000-03-24 15:04 x86 linux GDB and SIGALRM Jonathan Larmour @ 2000-03-27 2:03 ` Andrew Cagney 2000-03-27 2:20 ` Mark Kettenis 2000-04-01 0:00 ` Andrew Cagney 2000-04-01 0:00 ` Jonathan Larmour 1 sibling, 2 replies; 9+ messages in thread From: Andrew Cagney @ 2000-03-27 2:03 UTC (permalink / raw) To: Jonathan Larmour; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: x86 linux GDB and SIGALRM 2000-03-27 2:03 ` Andrew Cagney @ 2000-03-27 2:20 ` Mark Kettenis 2000-04-01 0:00 ` Mark Kettenis 2000-04-10 14:21 ` Jonathan Larmour 2000-04-01 0:00 ` Andrew Cagney 1 sibling, 2 replies; 9+ messages in thread From: Mark Kettenis @ 2000-03-27 2:20 UTC (permalink / raw) To: ac131313; +Cc: jlarmour, gdb 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: x86 linux GDB and SIGALRM 2000-03-27 2:20 ` Mark Kettenis @ 2000-04-01 0:00 ` Mark Kettenis 2000-04-10 14:21 ` Jonathan Larmour 1 sibling, 0 replies; 9+ messages in thread From: Mark Kettenis @ 2000-04-01 0:00 UTC (permalink / raw) To: ac131313; +Cc: jlarmour, gdb 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: x86 linux GDB and SIGALRM 2000-03-27 2:20 ` Mark Kettenis 2000-04-01 0:00 ` Mark Kettenis @ 2000-04-10 14:21 ` Jonathan Larmour 2000-05-01 11:53 ` [RFA] " Mark Kettenis 1 sibling, 1 reply; 9+ messages in thread From: Jonathan Larmour @ 2000-04-10 14:21 UTC (permalink / raw) To: Mark Kettenis; +Cc: gdb 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; } ^ permalink raw reply [flat|nested] 9+ messages in thread
* [RFA] Re: x86 linux GDB and SIGALRM 2000-04-10 14:21 ` Jonathan Larmour @ 2000-05-01 11:53 ` Mark Kettenis 2000-05-01 14:05 ` Jim Blandy 0 siblings, 1 reply; 9+ messages in thread From: Mark Kettenis @ 2000-05-01 11:53 UTC (permalink / raw) To: jlarmour; +Cc: gdb, gdb-patches, ezannoni, jimb [ 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. */ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFA] Re: x86 linux GDB and SIGALRM 2000-05-01 11:53 ` [RFA] " Mark Kettenis @ 2000-05-01 14:05 ` Jim Blandy 0 siblings, 0 replies; 9+ messages in thread From: Jim Blandy @ 2000-05-01 14:05 UTC (permalink / raw) To: Mark Kettenis; +Cc: jlarmour, gdb, gdb-patches, ezannoni 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. */ > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: x86 linux GDB and SIGALRM 2000-03-27 2:03 ` Andrew Cagney 2000-03-27 2:20 ` Mark Kettenis @ 2000-04-01 0:00 ` Andrew Cagney 1 sibling, 0 replies; 9+ messages in thread From: Andrew Cagney @ 2000-04-01 0:00 UTC (permalink / raw) To: Jonathan Larmour; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* x86 linux GDB and SIGALRM 2000-03-24 15:04 x86 linux GDB and SIGALRM Jonathan Larmour 2000-03-27 2:03 ` Andrew Cagney @ 2000-04-01 0:00 ` Jonathan Larmour 1 sibling, 0 replies; 9+ messages in thread From: Jonathan Larmour @ 2000-04-01 0:00 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2000-05-01 14:05 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-03-24 15:04 x86 linux GDB and SIGALRM Jonathan Larmour 2000-03-27 2:03 ` Andrew Cagney 2000-03-27 2:20 ` Mark Kettenis 2000-04-01 0:00 ` Mark Kettenis 2000-04-10 14:21 ` Jonathan Larmour 2000-05-01 11:53 ` [RFA] " Mark Kettenis 2000-05-01 14:05 ` Jim Blandy 2000-04-01 0:00 ` Andrew Cagney 2000-04-01 0:00 ` Jonathan Larmour
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).