From owner-freebsd-current Fri Jun 13 18:21:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA01568 for current-outgoing; Fri, 13 Jun 1997 18:21:25 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA01563 for ; Fri, 13 Jun 1997 18:21:22 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id LAA11120 for current@freebsd.org; Sat, 14 Jun 1997 11:15:44 +1000 Date: Sat, 14 Jun 1997 11:15:44 +1000 From: Bruce Evans Message-Id: <199706140115.LAA11120@godzilla.zeta.org.au> To: current@freebsd.org Subject: gdb-remote stepping of spls broken by non-inline spls Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk gdb-remote has strange problems with single stepping into splx(). This is probably caused by spl*() changing from inline functions to ordinary ones. gdb apparently uses breakpoints for skipping function prologues, but spltty() and splx() are used by the low level console i/o routines, so putting a breakpoint in them is fatal. spl*() are supposed to be compiled with -fomit-frame-pointer to avoid having prologues for efficiency, but I broke that when I fixed the profiling case (substition on make variables is more irregular than I thought). Compiling with -fomit-frame-pointer seems to have fixed the single stepping problems. Putting a breakpoint in splx() is still fatal. The symptom is that the remote keeps sending '$' and gdb is hard to kill. I'm surprised that it doesn't cause recursive breakpoint traps. There is no problem in ddb, since the debugger removes breakpoints before doing i/o. Remote debuggers should avoid the problem in a similar way, by putting the remote in charge of setting and removing breakpoints on debugger exit and entry. Bruce