From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8210 invoked by alias); 16 Mar 2009 19:04:25 -0000 Received: (qmail 8200 invoked by uid 22791); 16 Mar 2009 19:04:24 -0000 X-SWARE-Spam-Status: No, hits=-3.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 16 Mar 2009 19:04:20 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LjI6j-0002Sa-Kp for gdb@sources.redhat.com; Mon, 16 Mar 2009 19:04:17 +0000 Received: from mobius.qnx.com ([209.226.137.108]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Mar 2009 19:04:17 +0000 Received: from aristovski by mobius.qnx.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Mar 2009 19:04:17 +0000 To: gdb@sources.redhat.com From: Aleksandar Ristovski Subject: Re: [RFC] stepping over permanent breakpoint Date: Mon, 16 Mar 2009 19:04:00 -0000 Message-ID: References: <200903161850.n2GIoZgc021072@brahms.sibelius.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) In-Reply-To: <200903161850.n2GIoZgc021072@brahms.sibelius.xs4all.nl> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-03/txt/msg00091.txt.bz2 Mark Kettenis wrote: >> From: Aleksandar Ristovski >> Date: Mon, 16 Mar 2009 13:40:49 -0400 >> >> Hello, >> >> When there is a hard-coded breakpoint in code, like in this >> example (for x86): >> >> #include >> >> int main() >> { >> __asm(" int $0x03\n"); >> printf("Hello World\n"); >> return 0; >> } >> >> gdb on linux will appear to work correctly. > > Well, on Linux, that instruction will not be interpreted as a > permanent breakpoint, just like on QNX. Except on QNX gdb will not be able to continue or step over that instruction. > >> However, on systems that do not need pc adjustment after >> break (like QNX) gdb will not be able to step over that >> breakpoint unless user explicitly sets a breakpoint on top >> of it. > > The big question here is whether a breakpoint trap instruction should > always be interpreted as a permanent breakpoint in GDB or that it only > gets interpreted as such if you actually tell GDB about it. Up until > now, we've always done the latter. If you don't tell GDB, random > breakpoint trap instructions are handled as normal instructions and > you get to see whatever the architecture/OS does for these > instructions. Yes, this is my dilemma. I think we could print more informative message, but I am not sure. > >> I think that in case of linux it is actually working by >> accident - because kernel does not back-up instruction >> pointer after hard-coded breakpoint instruction was >> executed. Gdb will receive SIGTRAP but will not really know why. >> >> Attached patch fixes this for systems where >> gdbarch_decr_pc_after_break (gdbarch) == 0 > > If you want to fix things, it should be fixed for *all* systems. > What I proposed only brings in line those systems and makes them able to continue after hitting a permanent breakpoint (so on systems that normally do not need adjustment, I added advancing over the hardcoded breakpoint).