From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8910 invoked by alias); 18 Oct 2013 16:17:22 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 8900 invoked by uid 89); 18 Oct 2013 16:17:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 18 Oct 2013 16:17:21 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r9IGHHOu007924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Oct 2013 12:17:17 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r9IGHFje003639; Fri, 18 Oct 2013 12:17:16 -0400 Message-ID: <52615F0B.4050008@redhat.com> Date: Fri, 18 Oct 2013 16:17:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andrew Burgess CC: "gdb-patches@sourceware.org" , lgustavo@codesourcery.com Subject: I think permanent breakpoints are fundamentally broken as is (was: Re: [PATCH] Permanent breakpoints degrade to normal breakpoints on enable) References: <52614A15.7070301@broadcom.com> In-Reply-To: <52614A15.7070301@broadcom.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-10/txt/msg00574.txt.bz2 On 10/18/2013 03:47 PM, Andrew Burgess wrote: > This patch: > https://sourceware.org/ml/gdb-patches/2012-01/msg00964.html > > introduced what I believe is a stray line that causes permanent > breakpoints to become normal breakpoints if the user ever tries > to "enable" the permanent breakpoint. I actually think "permanent breakpoints" are quite weird beasts, both from a user interface, and implementation perspectives. First, they're displayed as enabled=='n': (gdb) b main Breakpoint 3 at 0x40053c: file ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S, line 29. (gdb) info breakpoints Num Type Disp Enb Address What 3 breakpoint keep n 0x000000000040053c ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29 If one can't ever disable those, then that's just ... odd, to say the least. Then, why can't you really disable them? If one adds commands to such a breakpoint, they're _always_ ran: (gdb) start Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.arch/i386-permbkpt ... Temporary breakpoint 1, main () at ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29 29 int3 (gdb) b main Breakpoint 2 at 0x40053c: file ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S, line 29. (gdb) info breakpoints Num Type Disp Enb Address What 2 breakpoint keep n 0x000000000040053c ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29 (gdb) commands Type commands for breakpoint(s) 2, one per line. End with a line saying just "end". >echo "hello!" >end (gdb) disable 2 (gdb) start The program being debugged has been started already. Start it from the beginning? (y or n) y Temporary breakpoint 3 at 0x40053c: file ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S, line 29. Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.arch/i386-permbkpt Breakpoint 2, main () at ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29 29 int3 "hello!"(gdb) I claim that one should be able to disable such a breakpoint, and that GDB would behave just like it the user hadn't created it that case. And then, "permanent"-ness is a property of the breakpoint. But it should actually be an implementation detail of a _location_. This bit in infrun.c: /* Normally, by the time we reach `resume', the breakpoints are either removed or inserted, as appropriate. The exception is if we're sitting at a permanent breakpoint; we need to step over it, but permanent breakpoints can't be removed. So we have to test for it here. */ if (breakpoint_here_p (aspace, pc) == permanent_breakpoint_here) { if (gdbarch_skip_permanent_breakpoint_p (gdbarch)) gdbarch_skip_permanent_breakpoint (gdbarch, regcache); else error (_("\ The program is stopped at a permanent breakpoint, but GDB does not know\n\ how to step past a permanent breakpoint on this architecture. Try using\n\ a command like `return' or `jump' to continue execution.")); } will do nasty things if we have a multiple location breakpoint where the whole breakpoint was set to "permanent" if one of the locations happened to be permanent, but the one GDB is resuming from is not... (I'm not even sure the whole "if you want to have GDB move past a hardcoded trap for you, set a breakpoint on top" user interface is actually sane at all. Could make more sense to actually have a "permanent breakpoint" command, distinct from a normal breakpoint. Then, continuing from a normal breakpoint on top of a trap would actually execute the trap, and report the SIGTRAP to the user, giving the user control over whether to pass that signal back to the program). -- Pedro Alves