From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 474 invoked by alias); 16 Mar 2009 19:38:21 -0000 Received: (qmail 465 invoked by uid 22791); 16 Mar 2009 19:38:21 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 16 Mar 2009 19:38:16 +0000 Received: (qmail 17006 invoked from network); 16 Mar 2009 19:38:14 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 16 Mar 2009 19:38:14 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: [RFC] stepping over permanent breakpoint Date: Mon, 16 Mar 2009 19:38:00 -0000 User-Agent: KMail/1.9.10 Cc: Aleksandar Ristovski References: <200903161822.29862.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200903161938.13219.pedro@codesourcery.com> 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/msg00092.txt.bz2 On Monday 16 March 2009 18:55:27, Aleksandar Ristovski wrote: > Pedro Alves wrote: > > On Monday 16 March 2009 17:40:49, Aleksandar Ristovski wrote: > >> However, on systems that do not need pc adjustment after=20 > >> break (like QNX) gdb will not be able to step over that=20 > >> breakpoint =A0(...) > >=20 > >> (...) unless user explicitly sets a breakpoint on top =A0 > >> of it. > >=20 > > Which I think your patch breaks? =A0:-) >=20 > No, it doesn't, it will behave as before. Observe where is=20 > the code I added, it is inside > if (gdbarch_decr_pc_after_break (gdbarch) =3D=3D 0) > so for linux, it won't even be executed. Not all architectures that run linux need PC adjustment. You're thinking x86-linux. Anyway, I meant that you're breaking setting a user breakpoint on top of a permanent breakpoint. Try setting a breakpoint with "break *int3_addr", on top of that int3, and running to it. When it is hit, you're moving the PC passed it, so later calls to bpstat_stop_status like: /* See if there is a breakpoint at the current PC. */ ecs->event_thread->stop_bpstat =3D bpstat_stop_status (stop_pc, ecs->= ptid); ... will not see the permanent breakpoint, right? > I have tried path similar to what you suggest. It seems more=20 > correct, but I would think that in addition to what you are=20 > doing, it would also need a change in adjust_pc_after_break=20 > to still decrement PC (to point to just-hit hardcoded=20 > breakpoint). Normally, adjust_pc_after_break will (on linux)=20 > miss this case and leave pc to point to instruction=20 > following breakpoint instruction. Yeah, I considered that, but I think that it is legitimate to want to pass SIGTRAPs to the inferior, and have a SIGTRAP handler see whatever it would see if GDB wasn't there. This may be useful for debugging programs that embed a gdb stub in process, for example. So, on decr_pc_after_break !=3D 0 targets, I'd leave things as they are. Mark's point about considering a trap instruction as a normal instruction is valid, so I'm not sure if we'd want to do this skipping by default or not. I'll let you guys fight over it. :-) --=20 Pedro Alves